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

Question

I'm facing an issue with a SharePoint menu customization and would appreciate any guidance.

I made the required code changes to fix the menu behavior, rebuilt and deployed the solution, and verified that the latest package/version has been successfully deployed. The App Catalog also shows the updated solution version, confirming that the deployment was completed correctly.

However, when testing the functionality, SharePoint still appears to be executing the old code instead of the newly deployed code. It seems like an older JavaScript bundle is still being loaded or cached somewhere.

What I've already verified:

Code changes were implemented successfully.

Solution package was rebuilt and deployed.

Latest version is visible in the App Catalog.

Deployment completed without errors.

Issue: Despite the above, the application continues to behave as if the old code is being executed.

Has anyone encountered a similar issue? Are there any additional steps I should check, such as cache invalidation, bundle versioning, CDN caching, or SharePoint asset deployment?

Any suggestions would be greatly appreciated.

Thanks!

Answer 1

Hello G Saikiran Reddy,

Based on my research, the latest version displayed in the App Catalog only confirms that the updated package has been uploaded and deployed. It does not necessarily mean that the browser or SharePoint site is loading the latest JavaScript bundle.

Some possible causes include:

• The previous JavaScript bundle is still cached by the browser, SharePoint, or the CDN.
• The newly uploaded package still contains an older bundle because the build folders were not cleaned before packaging.
• The JavaScript assets were not packaged correctly. If automatic asset hosting is being used, please confirm that includeClientSideAssets is set to true.
• An older CustomAction, component ID, or extension registration may still exist on the affected site.
• If the bundle is hosted on an external CDN, uploading a new .sppkg file will not automatically update the JavaScript files at the external location. The latest bundle must also be uploaded to the correct CDN path.

For reference:

• Host your client-side web part from Microsoft 365 CDN
• Host an SPFx extension from Microsoft 365 CDN

You can also refer to the AI-generated answer in this thread for additional troubleshooting suggestions. For example, you may first test whether the behavior is related to caching:

• Open the affected SharePoint site in an InPrivate or Incognito window.
• Perform a hard refresh by pressing Ctrl + F5.
• Open Developer Tools > Network.
• Enable Disable cache, and then reload the page.
• Check the URL and file name of the JavaScript bundle being loaded.

If the old code is still executed in an InPrivate or Incognito window, the issue is likely not limited to the local browser cache.

You may then completely clean and rebuild the solution. Depending on the SPFx and toolchain version, consider removing old build artifacts such as:

• dist
• lib
• release
• sharepoint/solution
• temp

After cleaning the project, perform a new production build and package. For newer Heft-based projects, the commands are:

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

Please also verify that the following setting is present in config/package-solution.json:

JSON
"includeClientSideAssets": true

If Microsoft 365 CDN or automatic asset hosting is being used, this setting is important because it controls whether the JavaScript assets are included in the .sppkg package.

To confirm that the correct package is being deployed, you may also:

• Increase the version number in package-solution.json.
• Rebuild and repackage the solution.
• Verify the timestamp of the generated .sppkg file.
• Remove the older package from the App Catalog Recycle Bin if necessary.
• Upload the newly generated package and deploy or enable it again.

Since this is a menu customization, the solution may be using an Application Customizer. Please also check whether the affected site contains multiple extension registrations or CustomAction entries with the same component ID. If an older registration still exists, SharePoint may continue loading the previous extension or passing older properties to it.

I hope this information helps.

Answer 2

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