Sp-dev-docs: Debugging SPFx webparts in production doesn't load webpart manifests from localhost

[phillipharding]

Category

• [x] Bug

Describe the bug

The scenario is that a solution package _(eg. version 0.0.0.1)_ containing a webpart (Webpart-A) is bundled and packaged using --ship and then deployed to the app catalog and installed to a site collection.

Webpart-A is then added to a page - the webpart bundle and manifest is being served from the app catalog.

In VSCode I updated the solution package version numbers _(eg. version 0.0.0.2)_ and then edit Webpart-A and want to debug - I run gulp build/bundle/package-solution without using --ship and then gulp serve --no-browser and open the page with Webpart-A on and append ?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js and select Load debug scripts when prompted - see (https://docs.microsoft.com/en-us/sharepoint/dev/spfx/debug-modern-pages#debug-sharepoint-framework-web-parts-on-modern-sharepoint-pages).

The webpart bundle and manifest for Webpart-A is still being served from the app catalog rather than localhost and so any changes I've made to Webpart-A do not materialise on the page, even if I delete Webpart-A from the page and re-add it back.

I then scaffold a new webpart (Webpart-B) to the solution, run gulp build/bundle/package-solution without using --ship and then gulp serve --no-browser and open the page with Webpart-A on and append ?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js and select Load debug scripts when prompted

I edit the page and the webpart picker dialog now also shows Webpart-B which I can then add to the page and debug as expected.

Both webparts display the version numbers from package-solution.json and the webpart manifest (package.json) so at this point the webparts should be showing 0.0.0.2 and 0.0.2 respectively.

Webpart-A shows a package-solution version of 0.0.0.2 and the webpart manifest version of 0.0.1

Webpart-B shows a package-solution version of 0.0.0.2 and the webpart manifest version of 0.0.2

If I open the same page now in maintenance mode (maintenancemode=true) and show the manifest data for Webpart-A and Webpart-B.....

Webpart-A shows a webpart manifest version of 0.0.1

Webpart-B shows a webpart manifest version of 0.0.2

If I open the manifest.js file served from localhost _(https://localhost:4321/temp/manifests.js)_ in the browser devtools, the manifest served within for Webpart-A correctly shows 0.0.2.

Steps to reproduce

See above

Expected behavior

Production webparts deployed to the app catalog should be able to be debugged using the ?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js method and should load the webpart bundle code and manifests from localhost

Environment details (development & target environment)

• Your Developer Environment: MacOS 10.15.6
• Target Environment: SharePoint Online
• Framework: Node.js v10.22.0
• Browser(s): Chrome | Chromium Edge
• Tooling: VS Code 1.49.0 | Typescript 4.0.2 | SPFx v1.11.0

Additional context

The scenario has previously worked as described in Expected behaviour until very recently

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[phillipharding]

Tried the same scenario with an SPFx 1.8.2 project and it worked as expected

[jaywellings]

I have observed this same issue. Additional information

1) when we use the hosted workbench for a site that has the webpart installed and working on a page, the hosted workbench will only show the web part as deployed in the app catalogue ( What I would consider not working as expected, the deployed version appears to be taking priority over the localhost version) .
2) when we use a hosted workbench for a site that _does not_ has the webpart installed and working on a page, the hosted workbench will show the webPart being served via localhost (What I would consider working as expected) .
3) this does not impact localhost workbench
4) We can verify this is not a code issue by going to the hosted workbench that is "not working" altering the id in the WebPart.manifest.json file to a "new id" this results in the web part as installed to show AND allows us to add the "debug" web part with the new ID.
5) we are only using the tenant level app catalog and not site level catalogs.
6) our app is tenant deployed, rather than deployed on a site by site basis.

Workaround currently
1) alter the "ID" and "default title" in the manifest. Add "Debug" in the title
2) go to the page where we have the Web part already hosted appending the ?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/manifests.js to the query string
3) agree to the debug scripts
4) add another instance of the web part, but this adding the "Debug" version
5) debug away

This appears to work because I think we are identifying our web part as a "new" web part due to the new Manifest ID.

Environment Details
Your Developer Environment: Windows 10
Target Environment: SharePoint Online
Framework: Node.js v10.22.0
Browser(s): Chrome | Chromium Edge
Tooling: VS Code 1.49.0 | Typescript 4.0.2 | SPFx v1.10.0 & 1.11.0

[Dave-Buck]

I can also confirm the observed issue. Issue occurring for me on SPFx 1.10 and 1.11 and different versions of Node.

The work around described above does work but is not ideal. This was working up until recently.

Environment Details
Your Developer Environment: Windows 10
Target Environment: SharePoint Online
Framework: Node.js v10.21.0-10.22.1
Browser(s): Chrome | Chromium Edge | IE11
Tooling: VS Code 1.49.0 | Typescript 4.0.2 | SPFx v1.10.0 & 1.11.0

[phillipharding]

A further observation today

The issue described seems to happen when the version information from package.json and package-solution.json differ from those that the solution package is deployed with.

_e.g._
I deploy a solution package to the App Catalog with version 0.0.1/0.0.1.0

Later in VSCode, I change the version number information in package.json and package-solution.json to 0.0.2/0.0.2.0

I run gulp serve --no-browser

I append the debug query string to the SharePoint page with the webpart on

?debug=true&noredir=true&loadSPFX=true&debugManifestsFile=https%3A%2F%2Flocalhost%3A4321%2Ftemp%2Fmanifests.js

Now, SharePoint is not loading the webpart manifest from localhost.

If I keep the version information the same as that deployed in the solution package, 0.0.1/0.0.1.0 in this case, then the webpart manifest is loaded from localhost, and I can debug as expected.

[jaywellings]

I can confirm @phillipharding observation is the cause and resolution to our issue.

The workaround: _deployed package, package.json and package-solution.json all need to have the same version number._

@phillipharding - great bit of bug hunting there! This approach is also a lot more elegant than what I suggested. so thank you, good sir!

I am however left wondering has something changed recently, our internal workflow has not changed significantly in the last 12 months and it would be very improbable that in the whole time these 3 numbers have not deviated during development.

[Abderahman88]

Very nice finding. I was wondering why my debugger breakpoints were not triggering 👍