SPFx Solution Updated and Deployed, but SharePoint Continues to Execute Old Code

The App Catalog version alone does not prove that the updated JavaScript bundle is being served; identify the bundle URL in browser developer tools, then update the asset source—ClientSideAssets/Microsoft 365 CDN or an external CDN—that the deployed manifest actually references.

1. Identify which bundle SharePoint loads

1. Open the affected SharePoint page in an InPrivate/Incognito window.
2. Open Developer tools → Network, filter for JS, and reload the page.
3. Select the SPFx extension bundle and record:
   • Request URL
   • JavaScript filename, including its hash
   • HTTP status
   • Response content or a unique string from the new code
4. In Sources or the response body, search for a string introduced by your change.

SPFx production script files receive content-specific hashes. If the requested filename/hash did not change, the package was likely produced from stale build output or the wrong source revision. If the filename changed but its response still contains old code, the asset host or CDN is serving incorrect content.^1^

2. Apply the branch matching that URL

Bundle comes from ClientSideAssets or Microsoft 365 CDN

Check config/package-solution.json:

{
  "solution": {
    "includeClientSideAssets": true
  }
}

With this setting, JavaScript assets are included in the .sppkg and deployed to SharePoint's ClientSideAssets location. If Microsoft 365 CDN is unavailable, SharePoint can automatically load them directly from the App Catalog site's ClientSideAssets folder.^2^

Perform a clean production build using the commands appropriate to the project's SPFx toolchain:

SPFx 1.22+ Heft-based project:

heft build --clean --production
heft package-solution --production

SPFx 1.0–1.21.x Gulp-based project:

gulp clean
gulp bundle --ship
gulp package-solution --ship

The Heft and Gulp production equivalents are documented here.^3^

Before replacing the package again:

1. Rename the newly generated .sppkg to .zip.
2. Extract it and inspect the manifests/assets.
3. Confirm that the referenced bundle has a new hash and contains the changed code.
4. Upload that verified package to the same App Catalog from which the affected tenant/site consumes the solution.

This is a new package verification step, not another blind redeployment.

Bundle comes from an external CDN or storage endpoint

Check config/write-manifests.json. A real URL in cdnBasePath means the package points SharePoint to externally hosted scripts. In that configuration, updating only the .sppkg does not publish the JavaScript files; the generated production assets must also be copied to the configured CDN.^4^

For Azure Storage/CDN with a current Heft project:

heft build --production
heft deploy-azure-storage --production
heft package-solution --production

For another CDN provider, publish the generated files from release/assets to the exact cdnBasePath location before deploying the package. External hosting normally uses includeClientSideAssets: false; the CDN deployment and .sppkg deployment are separate operations.^5^

Verify the exact bundle URL directly afterward. It must return the new bundle—not merely HTTP 200—and the page must request that new hashed filename.

3. If the new bundle is loaded but behavior remains old

If Developer Tools proves the response contains the changed code, this is no longer an asset-cache issue. Check:

• Whether another extension with the same menu purpose is also registered on the site, list, or tenant.
• Whether the changed branch executes by adding a temporary unique console.info marker.
• Whether a service worker is supplying the response; inspect the Network request's Size/Transferred and initiator details.
• Whether the bundle or dependencies return 403/404. App Catalog-hosted assets require users to have access to the origin; CDN-origin or permission failures should be resolved at the serving location.^6^

Do not purge or overwrite an old hashed bundle as the primary fix. SPFx generates uniquely named bundles for changed content, and previous files can still be required by existing component instances.^1^

References

1. SharePoint Framework enterprise guidance
2. Host your client-side web part from Microsoft 365 CDN (Hello World part 4)
3. Implement Continuous Integration and Continuous deployment using Azure DevOps
4. Support for Content Security Policy (CSP) in SharePoint Online
5. Deploy your SharePoint client-side web part to Azure CDN
6. Unexpected rendering failure in custom SharePoint web part after recent platform updates - Microsoft Q&A