Skip to main content
How to deploy Lightning Web Components (LWC)

Deploying LWC with Gearset, and resolving merge conflicts

Claudia McPhail avatar
Written by Claudia McPhail
Updated over 3 months ago

Lightning Web Components (LWC) are an important part of many teams' customization of their Salesforce instances. If you’d like to learn more about developing Lightning Web Components using Gearset we recommend this trail on trailhead.

In this document, we will show you how to deploy LWC using Gearset, as well as cover some key scenarios that many users encounter when developing LWC:

  • Two developers editing different files on the same component

  • Two developers editing the same file on the same component

How to deploy a Lightning Web Component using Gearset

LWC are a selectable component in the Gearset compare and deploy process.

To see the LWC make sure that you have included them in your metadata filter when running the comparison.

This is an example of how the LWC will appear in your comparison results.

You can select this and deploy it to your target environment.

If you're using source control and continuous integration you can select this LWC, commit it to your master branch, and allow Gearset CI/CD to propagate that to all of your environments.

This version of the LWC will now be live.

Changes to different files in the same Lightning Web Component

Working on a Lightning Web Component at the same time as your teammate is a common scenario. As many developers using Source Control know, working separately on the same Salesforce component can trigger a merge conflict.

The following section details how Gearset handles that situation for LWC, using source control and the Gearset platform.

In this example, we have 2 sandboxes. Each of them is a location where developers are working separately.

Developer 1 and Developer 2 both create feature branches from Master (using Gearset) and commit the changes they’ve made to their own versions of the LWC files.

They are working in separate branches, both of which were created from Master.

Developer 1 edits the HTML file in the Dev1 branch.

Developer 2 edits the js file in the Dev2 branch.

Developer 1 opens a pull request to the Master branch, and Gearset validates the pull request.

The pull request is reviewed and merged. Developer 1’s change is now in the Master branch.

Developer 2 opens a pull request to the Master branch, which has been changed since their feature branch was originally created.

Gearset validates the pull request and the element which was altered by Developer 2 (the js file).

GitHub is able to recognize that the only file altered by Developer 2 is the js file, and therefore this is the only change contained in the pull request.

The 2nd pull request is merged, and the final version of the LWC contains changes from Developer 1 and Developer 2.

Two developers editing the same file on the same component

In this example Developer 3 and Developer 4 also work in separate sandboxes.

They both edit the HTML component of the same LWC, but in separate environments. They are not aware of the other person's changes.

Developer 3 edits one of the lines in the HTML file. They commit this to a feature branch using Gearset, which is created from Master. They open a pull request to Master using Gearset. After they get a notification that the validation and LWC tests have run, the branch is merged into Master.

Developer 4 also edits one of the lines in the HTML file, they also commit this to a feature branch created from Master, that was created at the same time as Developer 3. They open a pull request to Master using Gearset.

However, this does not successfully pass the GitHub merge conflict checks. Because two people have made changes to the same file GitHub now needs to confirm which one of these changes are correct - or if the two sets of changes need to be merged.

We can use the ‘Resolve conflicts’ option in GitHub to resolve this. Clicking that button opens up a helpful UI, which highlights the conflicting lines.

The Developer is able to manually choose which lines they would like to keep, in this case, the comments from both Developers 3 and 4.

Please see this video for an example. The method for conflict resolution will vary depending on your Source Control provider, in this example we have used GitHub.

After the merge conflict has been resolved, the pull request can be merged and the changes will go live.

We want to hear from you!

If there are use cases that you want to confirm that Gearset supports, or any suggestions that you'd like to submit to our product team please let us know using our feedback forum or in-app chat!

Did this answer your question?