SPFx 'gulp clean' - don't neglect its use during deployments


I recently ran into a situation where building and debugging a SPFx web part seemed to go off the rails. Then I figured out that my normal pattern of skipping the ‘gulp clean’ command during project deployment had cause what I thought was bizarre behavior in Site Collection Features and toolbox.

I was working for a client that does not have a dedicated development or QA environment due primarily to political reasons. They also block access to all non-company tenants. Fortunately, I am able to do my development “off network” and once everything is ready, I move the code inside the firewall. Since this was an update to an existing web part, I knew deploying it to the same tenant as the existing web part was going to be tricky. The existing web part is on the company intranet home page, so getting into a site for testing without affecting the original web part meant deploying into a “QA” site app catalog. I thought this would work and there shouldn’t be any conflict. Famous last words …

After deploying the updated web part to the QA site app catalog, it wasn’t showing up in the toolbox to add to the page. It also wasn’t listed on the Site Feature page. I tried several things, like deleting the solution package and re-uploading, but still had the same results. I did some research and found guidance that I needed to change the Component ID and the PackageID so as to not conflict with the tenant level web part. So I did and redeployed.

Now I had multiple Features and 3 web parts! Nothing worked!

To make a long story short(er), I had neglected to run “gulp clean” before bundling and packaging the web part with the changed IDs. SPFx creates the feature needed to activate your web part when you package the solution in the “gulp package-solution –ship” command. The feature definition files are named based on the Component ID of your web part. If you do not run “gulp clean” before bundling and packaging your solution, the old feature files are still in the package and create multiple features, some of which point to the tenant deployed web part. SharePoint does not like this!! Not one bit!!

Simple solution: Remember to run “gulp clean” before the “gulp bundle –ship” command. Do this every time as a good practice habit, but you MUST run it if you change the Component ID of your solution.

See you soon!