SPFx 1.21 RC changes location of manifest.js

[jhholm]

What type of issue is this?

Question

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Target SharePoint environment

SharePoint Online

What browser(s) / client(s) have you tested

• 💥 Internet Explorer
• 💥 Microsoft Edge
• 💥 Google Chrome
• 💥 FireFox
• 💥 Safari
• mobile (iOS/iPadOS)
• mobile (Android)
• not applicable
• other (enter in the "Additional environment details" area below)

Additional environment details

No response

Issue description

Running SPFx local development with gulp serve has a small change introduced with 1.21-beta.2. The location of manifest.js has changed from temp/manifest.js to temp/build/manifest.js. So the URL to load debug scripts manually is different from prior versions and this is shown in the task log seen below.

Until 1.21-beta.2

[spfx-serve] To load your scripts, use this query string: ?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/manifests.js

Since 1.21-beta.2

[spfx-serve] To load your scripts, use this query string: ?debug=true&noredir=true&debugManifestsFile=https://localhost:4321/temp/build/manifests.js

This most definately is a nitpick, but this change will cause a breaking change with spfx-fast-serve. That can be easily handled as it's a versioned dependency, so no issue there.

This will also affect sp-editor which has a button to load the debug manifest. The location of the manifest.js will be different depending on the spfx version.

Additionally I guess some people have their own scripts that could break. I do understand things need to change, but I wanted to ask if this change was intentional?

[nick-pape]

Related: #10053

[Amey-MSFT]

Hello @jhholm ,
Thank you for bringing this issue to our attention. We will look into it and get back to you shortly.

[Amey-MSFT]

Hello @jhholm ,
Thanks for raising this!
Yes, the change in the manifest path from /temp/manifests.js to /temp/build/manifests.js in SPFx 1.21 is intentional and aligns with internal refactoring in the build pipeline. This impacts tooling like spfx-fast-serve and sp-editor which rely on hardcoded paths. You can track the official build behavior in the SPFx v1.21 release notes. It's recommended to update any dependent tools or scripts accordingly.

[VesaJuvonen]

@Amey-MSFT - Just to be clear - @nick-pape from the SPFx engineering side is currently looking into this and we might change the locations back. So let's not confirm any changes and ask ecosystem to do updates until we have the situation fully confirmed with the owning engineering team.

[Amey-MSFT]

Hello @jhholm ,
Please hold off on making any tooling or script updates until there's confirmation from the SPFx engineering team.
Thanks for the clarification @VesaJuvonen ,

[VesaJuvonen]

Hi,
just to confirm the outcome on this. Unfortunately this will be rolling out as by design - or by dependent changes - in the general availability version of SharePoint Framework 1.21. We will be mentioning this in the release notes to avoid any confusion on this and do acknowledge the potential inconvenience of this for the developers.

[jhholm]

It seems that the SharePoint Framework Hosted Workbench (_layouts/15/workbench.aspx) is trying to load from both locations. Is this functionality going to stay there, or can we expect older versions of SPFx to be "deprecated" at some point?

[VesaJuvonen]

@jhholm - to ensure that the online workbench works with all versions, it will keep on continuing supporting all locations. Technically we still support even SPFx v1.0 in the workbench and no plans to do breaking changes for customers and partners on that.

with the 1.21 - there's a known issue on the workbench wrongly showing a message that the localhost is not connected - even though web part will be in the picker. This will be addressed with server side fix in upcoming days/week(s) as the update will rollout in the hosting platform.

Closing this as answered - by design with 1.21 with the underlaying package changes. Not quite optimal due the impact on the open-source tooling, but was informed that there are no further work to be done in here.