[SalesForce] Not seeing changes to LWC after deploying via VSCode

I have a SFDX Force-App that contains all of my classes, lightning web components, objects, triggers, etc. I've uploaded this force-app to my sandbox and my changes in my lwc was there and looked good so now I'm attempting to deploy this force-app to my production environment.

So I followed these steps:

1) I ran

sfdx force:source:convert -P /path/to/source/force-app/MyForceApp/main/default

This outputted a folder like metadataPackage_12345

2) So then I zipped it up with:

zip -r -X JAN-19-2019.zip metadataPackage_12345

3) I then ran a test run via:

sfdx force:mdapi:deploy --checkonly --zipfile JAN-19-2019.zip

This gave me a JobId: 0Af3k00000IwyHETFJ

4) I ran

sfdx force:mdapi:deploy:report

to check the status and it completed successfully.

5) After this finished, I then went to actually deploy it

sfdx force:mdapi:deploy --validateddeployrequestid 0Af3k00000IwyHETFJ

This also ran and completed successfully.

I then logged into my SF Prod instance and navigated to Set Up > Environments > Deploy > Deployment Status and it shows both the validation and the deployment succeeded.

However, when I go to the location where I have my updated LWC, it doesn't appear to have my changes…

Is there any steps I'm missing to get the LWC to be updated?

Best Answer

Others new to LWC and LWC Trailhead: Lightning Web Components Basic may experience OP issue ...

In your VS Code project, in the LWC folder you will have

after step 2 Create Lightning Web Components of the Trailhead a LWC named BikeCard.
You'll deploy this to your Playground in Step 3 Deploy Lightning Web Conponents
In step 4 Handle Events in Lightning Web Components , depending on how you unzip the file Bike Selector App for Trailhead, you will now have an additional LWC called selector as well as the original bikeCard.
Note that file bikeCard.js-meta.xml is a LightningComponentBundle, note that file selector.js-meta.xml is also a LightningComponentBundle

When you do an SFDX: Deploy Source to Org, your VS Code project is deployed to your Trailhead Playground.

The instructions for step 4 ask you to create a new one-page one-region Lightning App. The LWC that you need to drag onto the canvas is called selector, not bikeCard! It is easy to get confused and think you updated the bikeCard LWC as the whole trailhead is about bikes. So, you may think your deploy failed or there is some caching issue. But no, you just chose the wrong LWC. Names matter. Good names are best - having bikeCard and selector in the same project was a poor choice by the Trailhead team.

Related Solutions

[SalesForce] DX is throwing an error while deploying to production

If your default org is not set to Production (which it likely is not - usually it's set to the current scratch org or sandbox that you're developing on), then you need to specify the org which you want to see the deployment status for.

You need the -u flag and point to your sfdx logged in Production org:

sfdx force:mdapi:deploy:report -u MyProductionOrgAlias

Bonus

In the original sfdx deploy command, try adding the -w flag with the number of minutes to wait, and you'll get auto-reporting in your terminal! No need to run the above reporting command

sfdx force:mdapi:deploy ... -w 5

[SalesForce] Salesforce deployment using Ant and SFDX

The Ant-based Force.com Migration Tool and SFDX CLI are both clients of the Metadata API. You need one or the other, but generally not both, as both tools provide Metadata API deployment services. Specifically, you don't need the Force.com Migration Tool to drive Salesforce DX. You can issue commands like sfdx force:mdapi:deploy directly via a shell script or your build system's configuration interface.

As to package.xml: if you're using Metadata API-format source code (typically in a src folder) and not SFDX-format source code (typically in a force-app folder), you'll need a package.xml manifest.

If you're using SFDX-format code, you may not need a manifest. SFDX's force:source commands (such as push, for scratch orgs, and deploy, for non-scratch orgs) don't require a manifest. Likewise, converting your SFDX-format source to MDAPI-format source via force:source:convert will create a manifest for you to make the result deployable using the Metadata API, via the force:mdapi:deploy command. (Note that if you're practicing the Org Development Model, without using source-tracking scratch orgs, you'll likely also have a package.xml under the manifest directory).

If you aren't familiar with the two source formats and aren't currently using Salesforce DX, your code is certainly in Metadata API format and does require a manifest for deployment.

Salesforce provides documentation covering CI setup on various providers, including sample repos. I wrote a series of blog posts on setting up SFDX-based CI using CircleCI some time ago.

Partial Deployments

Partial deployments are a completely separate issue from the above.

Salesforce's tooling does not include any support for partial or delta (i.e., change-only) deployments other than with source-tracking orgs (such as scratch orgs), where you can use sfdx force:source:push.

If you're deploying to sandboxes or production, you'll have to write your own scripts to generate a package.xml representing some arbitrary set of changes that you wish to deploy separately. There's not a single standard way to do that; it will depend on the whole scope of your tool chain and development process.

You do not have to use partial deployments to implement CI and CD. Unless your application is truly enormous, you can deploy the entire application to your persistent environments.

Best Answer

Related Solutions

[SalesForce] DX is throwing an error while deploying to production

[SalesForce] Salesforce deployment using Ant and SFDX

Partial Deployments

Related Topic