SharePoint / SharePoint/sp-dev-docs

debugManifestsFile property not accepting anything other than localhost

Open
#10,797 4 comments 0 reactions 1 assignee View on GitHub

@Ashlesha-MSFT is already working on this.

Since Apr 24, 2026.

Needs: Author Feedback sharepoint-developer-support
Dominant language
PowerShell
Stars
1.4k
Forks
1.1k
Avg merge
4d 12h
Merged PRs (30d)
12

Description

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
  • browser version
  • SPFx version
  • 1.22.1
  • Node.js version
  • etc
Issue description

I am trying to test a webpart on a SharePont online workbench from a different machine than the development SPFx is running on.

adding debugManifestsFile=https://somewhere.com:4321/temp/build/manifests.js used to work but now seems to be ignored unless it is localhost with some port.

I can look in the developer console and see that it doesn't even try to load the manifest from that url and instead reverts to localhost.

I know the property is being set correctly because if I do localhost with an obscure port like https://localhost:4444/temp/build/manifests.js it does indeed try to pull the manifest from that port.

I thought it could be related to CSP changes and added the domain (like https://somewhere.com) to the trusted scripts but that didn't have any effect.

Is there another setting to get it to pull the manifest from somewhere other than localhost?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.