I'm building a SharePoint SPFx react webpart.

I'm developing on a local level using workbench with a link similar to this: https://mysite.sharepoint.com/sites/sitehere/_layouts/15/workbench.aspx#/

Everything works great, however about 2 weeks ago when running gulp bundle --ship I started receiving a The build failed because a task wrote output to stderr. Exiting with exit code: 1 error.

I was reading here that I can use --debug instead. https://stackoverflow.com/questions/50968594/gulp-bundle-ship-the-build-failed-because-a-task-wrote-output-to-stderr

After running gulp bundle --debug and gulp package-solution --ship. I then replace the webpart in the App Catalog. This used to work perfectly fine but recently it stopped working. No matter what I do the webpart on the live SharePoint site will not update.

In my package-solution.json I change my version

  "$schema": "https://developer.microsoft.com/json-schemas/spfx-build/package-solution.schema.json",
  "solution": {
    "name": "app-webapp-client-side-solution",
    "id": "2af8ae0f-26e0-41c9-bd37-1e7fb1963074",
    "version": "",
    "includeClientSideAssets": true,
    "isDomainIsolated": false
  "paths": {
    "zippedPackage": "solution/procurement-webapp.sppkg"

I then remove the webpart from my page, delete the webpart from the site contents and recycling bin. Then delete it off the App Catalog. When I install the app in my App Catalog and add it again to my SharePoint site, when I hover it shows it's new and shows the new version. I then add the web part on the page again and still it shows the old one. I tried to clear cache 100 times.

I also noticed sometime I'll rebuild a few times with minor changes and it will finally update on the live site side but with a build from 3 versions ago. I've added the webpart and waited 3 days hoping it takes time to refresh and still doesn't work.

Any ideas?

1 Answer 1


@Hisusu32, You are leaving one critical step out of your deployment process; you are also missing additional debug steps you really need to perform in addition to what you describe.

There are two tasks you need to perform prior to gulp build and deployment into the app catalog site/library.

  1. Ensure that you increment the version in your project’s package.json and your project’s package-solution.json match - but there is a catch to it since package.json follows semantic versioning e.g.: 1.0.1 (Major.Minor.Patch). In contrast, package-solution.json uses a different versioning scheme for some reason: (Major.Minor.Patch.Revision_Number). You can read about the differences and idiosyncratic ways you can make the versioning programmatically increment using gulp here

Note: the 3 digits (e.g.: 1.1.2) in the package.json version need to match the first 3 of the 4 digits in the package-solution.json (e.g.:

If you do not increment the version number above the version already deployed - the newer version is not propagated, even when you follow the additional deployment step farther below.

  1. The other step you need to perform prior to deployment to SharePoint is figure out what is writing and what was written to stderr and remedy the issues. Follow the instructions on this post for stderr

Finally, the description of your deployment is missing one obvious step: clicking the deploy button in the tab in the app catalog library containing your .sppkg file.

I have forgotten to click the deploy button as well as not incrementing the version in both locations before.

If this helps, plz up-vote!

  • Thank you so much for your response. That increment version helped so much. So now my package.json + my package-solution.json are both on the same versions. So right now I'm doing gulp bundle --debug followed by gulp package-solution --ship. I tried another time where I upped the version so "" and "2.4.0" then doing build. Made sure the deploy displayed and since not working. I'm thinking now it's with the steps to build? Can you go in a little more detail on the build?
    – hisusu32
    Feb 19, 2021 at 21:17
  • Fritz I did notice when I do gulp build I get this Build target: DEBUG
    – hisusu32
    Feb 19, 2021 at 21:21
  • 1
    @hisusu32: by default, when you run the raw gulp build command, it is for debug, by default. This is the same with all the other commands, i.e: gulp bundle, gulp package-solution. In your previous comment, you stated that you ran gulp bundle —debug followed by gulp package-solution —ship. The output for the —debug switch and the —ship switch are sent to different folders. Instead, when building, bundling and packaging for production, always use the —ship switch for all of those tasks. Also, prior to any gulp build command, run gulp clean (no switch). This removes old, prior builds. Feb 20, 2021 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.