Non-default ports for SPFx don't seem to work

[westleyMS]

Target SharePoint environment

SharePoint Online

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

💥 SharePoint Framework

Developer environment

Windows

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

• browser version: 132.0.2957.115 (Official build) (64-bit)
• SPFx version: 1.19.0
• Node.js version: v18.20.4
• etc

Describe the bug / error

When trying to configure SPFx to use an alternate port for serving up the manifest and resources, it creates the manifest with the default port specified (4321) instead of the port specified in the serve.json-
{
"$schema": "https://developer.microsoft.com/json-schemas/spfx-build/spfx-serve.schema.json",
"port": 4322, //<- this is the port we want to debug with
"https": true,
"initialPage": "https://{tenantDomain}/_layouts/workbench.aspx?loadSPFX=true&debugManifestsFile=https://localhost:4322/temp/manifests.js&moduleloader=https://localhost:4322&debug=true"
}

I also tried to add the port to the write-manifests.json to control the port it puts in the manifest-
{
"$schema": "https://developer.microsoft.com/json-schemas/spfx-build/write-manifests.schema.json",
"cdnBasePath": "",
"manifestDeployCdnPath":"https://localhost:4322/", //<- I set this
"deployCdnPath":"https://localhost:4322/", //<- and this
"debugBasePath": "https://localhost:4322/", //<- and this
"cumulativeManifestOptions": {
"baseUrl": "https://localhost:4322/" //<- and this
}
}

I tried different places for adding the port, but none seemed to work, here was part of the resulting manifest.js generated in the temp folder-

var t = [{
"id": "120bc0e9-8217-475d-a165-8fff73631a21",
"alias": "HelloWorldWebPart",
"componentType": "WebPart",
"version": "0.0.1",
"manifestVersion": 2,
"requiresCustomScript": false,
"supportedHosts": ["SharePointWebPart", "TeamsPersonalApp", "TeamsTab", "SharePointFullPage"],
"supportsThemeVariants": true,
"preconfiguredEntries": [{
"groupId": "5c03119e-3074-46fd-976b-c60198311f70",
"group": {
"default": "Advanced"
},
"title": {
"default": "HelloWorld"
},
"description": {
"default": "HelloWorld description"
},
"officeFabricIconFontName": "Page",
"properties": {
"description": "HelloWorld"
}
}
],
"loaderConfig": {
"internalModuleBaseUrls": [https://localhost:4321/dist/,https://localhost:4322/dist/], //<- this has both ports
"entryModuleId":"hello-world-web-part",
"scriptResources":{
"hello-world-web-part":{"type":"path","path":"hello-world-web-part.js"},
"@microsoft/sp-core-library":{"type":"component","id":"7263c7d0-1d6a-45ec-8d85-d4d1d234171b","version":"1.19.0"},
"@microsoft/sp-webpart-base":{"type":"component","id":"974a7777-0990-4136-8fa6-95d80114c2e0","version":"1.19.0"}
}
}
},
{
"id":"73e1dc6c-8441-42cc-ad47-4bd3659f8a3a",
"alias":"SPLodashSubset",
"componentType": "Library",
"version":"1.19.0",
"manifestVersion":2,
"loaderConfig":{
"internalModuleBaseUrls":[https://localhost:4321/node_modules/@microsoft/sp-lodash-subset/dist/], //<- all modules have the default
"entryModuleId":"sp-lodash-subset",
"scriptResources":{
"sp-lodash-subset":{"type":"path","path":"sp-lodash-subset_3174f74d982968c6997c.js"}
}
}
} ....

Steps to reproduce

1. change the port in the places mentioned about (serve.json and write-manifests.json). Change from 4321 to 4322.
2. make sure to put in the initialPage param in the serve.json and specify the debugManifest.
3. run gulp clean, gulp build, gulp bundle, and gulp serve.
4. test the solution

Expected behavior

The manifest should load, the web part should be in the workbench toolbox, and when adding it should pull it from the correct path.

actual:
it pulls it from the default port path (https://localhost:4321/dist/....) because that is what is in the manifest, but the browser gets a 404 error since it is the wrong port, and the request fails. You can see this in the F12 tools.

[andrewconnell]

This is expected & you can't change the port like you're trying.

The hosted workbench is hardcoded to look for the manifest at a specific URL... https://locahost:4321.... You can't change this. The port you're specifying in the serve.json is used to configure your local webserver. when you're changing it, the hosted workbench will throw the 404's you see because it's not finding the manifest where it expects it.

You COULD use a real SharePoint pag to test them out as you can control where the manifest is loaded from, like you do with extensions, but you can't use the hosted workbench the way you're trying to do it.

This may help you understand it: https://www.voitanos.io/blog/spfx-5w1h-how-does-the-sharepoint-framework-work/

[westleyMS]

The manifest loads fine due to the query string in the launchUrl parameter in serve.json.
I confirmed this with a browser trace and can see the manifest load.

It is the manifest that has the bad links (see the manifest.json in the OP) that cause it not to work.
I thought that the parameters in the write-manifest.json were supposed to affect the way it writes the manifest.

[Ashlesha-MSFT]

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

[Ashlesha-MSFT]

@westleyMS,
Thanks for the detailed explanation. I followed the steps provided and made the necessary changes to both serve.json and write-manifests.json, updating the port from 4321 to 4322.
I got the expected result.

It seems that the issue lies in manifest.

[andrewconnell]

@westleyMS

I thought that the parameters in the write-manifest.json were supposed to affect the way it writes the manifest.

No, that's not correct.

The write-manifest.json file is used in the packaging process (the gulp task package-solution) which has nothing to do with the serve gulp task. It doesn't impact the manifest.js file; it impacts the JSON manifest created for the component.

It's used to change the location where packages are pulled from which is only used when you decide to use your own CDN. The cdnBasePath default value <!-- PATH TO CDN --> tells the packaging process to use its existing logic (ie: point to the O365 CDN... the default value is something like https://SPCLIENTSIDEASSETS which the SPFx runtime interprets as the current site's O365 CDN location.

If you instead deploy your assets (JS bundles, manifests, images, etc) for your package to a custom CDN (Azure, AWS, or something else hosted internally on an air-gapped SP deployment), if you change the cdnBasePath property to another location, like https://vtnsmasteringspfxcdn.azureedge.net/vtns-azure-cdn.