Sp-dev-docs: ?debugManifestsFile url is not working after upgrading to version 1.9.1

[pkmelee337]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

To do some debugging on production environments, I'm using the ?debugManifestsFile parameter a lot. My expected behavior was that this kind of debugging still worked after upgrading to version 1.9.1, but sadly it doens't.

Observed Behavior

The ?debugManifestsFile queryparameter does not work anymore. In my console I'm seeing an error "Unable to determine manifests.js file URL. Using default base URL.". After a little debugging I found out this is because the "webpack publicPath" could not be found on the current SharePoint page. I also compared the the 'manifestsFile.js' in @microsoft/sp-build-core-tasks with a previous version and found out this file changed indeed.

Steps to Reproduce

Upgraded an existing SPFx solution (1.8.2) to version 1.9.1, Removed node_modules folder, Even compared my package.json with a clean install, Installed the packaged, Uploaded a fresh package after a clean (with --ship) and debugged an extension using ?debugManifestsFile.

[msft-github-bot]

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

[andrewconnell]

Could you provide a bit more detail, like what you're using for the entire URL (what used to work, what doesn't work now), to make it easier to repro?

[pkmelee337]

Yes off course. Thanks for the fast reply. 👍 I've got a solution with multiple extensions which are already present on a sitecollection. The extensions are deployed in the whole tenant using 'skipFeatureDeployment' true. To debug them all at once at a production environment I'm using the following url: https://.sharepoint.com/sites/?debugManifestsFile=https://localhost:4351/temp/manifests.js&loadSPFX=true. (4351 is the port I also configured in my config/serve.json) This was working fine when using spfx 1.8.2, but when I upgraded to 1.9.1 I'm retrieving the error message described. Yesterday I downgraded back to 1.8.2 and everything is working fine again.

[pkmelee337]

Are there any updates on this one? We still have this issue. Also tested this in an spfx solution with only spfx webparts and they also have this problem. This happens on first release and non first release tenants.

[andrewconnell]

I'm not seeing this... I've verified across a few tenants and it's working just fine with 1.9.1. The only difference is that my URL is encoded like so:

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

[msft-github-bot]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within next 7 days of this comment. Thank you for your contributions to SharePoint Developer activities.

[pkmelee337]

I'm sorry for the late reply. Working on some other projects, but will try to test it this week. I did notice some changes on our tenant regarding serving spfx solutions, so hopefully this one is fixed.

[johnguy0]

@pkmelee337 Are you still seeing this issue?

[pkmelee337]

@johnguy0 , thanks for your reply. I will be updating our spfx packages next week and i'll let you know!

[msft-github-bot]

This issue has been automatically marked as stale because it has marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within the next 7 days of this comment. Please see our wiki for more information: Issue List Labels: Needs Author Feedback & Issue List: No response from the original issue author

[pkmelee337]

Hi @johnguy0 ,

I'm very sorry for the late reply, but the upgrading did cost me quite some time. First of all webpack packaging was taking very long and seemed to be landing in an infinite loop in the cumulativeManifestProcessor. After debugging the build process and finding out this was due to the npm package "fs" we were using in our gulpfile, I replaced this package with another one and I was able to create a package.

Building, Shipping and uploading went fine, and the package was working, but sadly I am still not able to debug my webparts and extensions. The errors described in my first message are gone, but I am now retrieving the following error message: 'Failed to load component "" (MyWebPart). Original error: Failed to load entry point from component "" (MyWebPart). Original error: Object prototype may only be an Object or null: undefined'

Off course I did some research and found this stackoverflow post for example. However, my solutions were debugging fine on version 1.8.2. I also don't think I'm referencing imports in a cyclical manner.

I have upgraded to spfx version 1.10.0. As said, without debugging the package works fine, this only happend when I'm debugging the package (only tried with a debugmanifesturl). My package.json is as followed:

{
  "name": "my-webpart-name",
  "version": "1.0.0",
  "private": false,
  "engines": {
    "node": ">=0.10.0"
  },
  "repository": "<our devops npm repository",
  "author": "<my name>",
  "license": "MIT",
  "scripts": {
    "serve:fast": "gulp sass && concurrently \"tsc -p tsconfig.json -w --preserveWatchOutput true\" \"gulp serve --nobrowser --fast-mode\"",
    "refreshVSToken": "vsts-npm-auth -config .npmrc",
    "build": "gulp bundle",
    "clean": "gulp clean",
    "test": "./node_modules/.bin/jest --config ./config/jest.config.json",
    "test:watch": "./node_modules/.bin/jest --config ./config/jest.config.json --watchAll"
  },
  "dependencies": {
    "@microsoft/decorators": "1.10.0",
    "@microsoft/microsoft-graph-types": "~1.9.0",
    "@microsoft/office-ui-fabric-react-bundle": "1.10.0",
    "@microsoft/sp-application-base": "1.10.0",
    "@microsoft/sp-core-library": "1.10.0",
    "@microsoft/sp-dialog": "1.10.0",
    "@microsoft/sp-listview-extensibility": "1.10.0",
    "@microsoft/sp-lodash-subset": "1.10.0",
    "@microsoft/sp-office-ui-fabric-core": "1.10.0",
    "@microsoft/sp-webpart-base": "1.10.0",
    "@microsoft/sp-http": "1.10.0",
    "@pnp/pnpjs": "~1.3.9",
    "@pnp/sp-taxonomy": "~1.3.9",
    "@pnp/spfx-property-controls": "~1.16.0",
    "@types/es6-promise": "0.0.33",
    "@types/jquery": "~3.3.22",
    "@types/applicationinsights-js": "~1.0.9",
    "@types/owl.carousel": "~2.3.1",
    "@types/react": "16.8.8",
    "@types/react-dom": "16.8.3",
    "@types/sharepoint": "~2016.1.0",
    "@types/webpack-env": "1.13.1",
    "core-js": "~3.0.1",
    "es6-map": "~0.1.5",
    "hammerjs": "~2.0.8",
    "immutable-ics": "^0.4.0",
    "jquery": "~3.3.1",
    "moment": "2.22.1",
    "muuri": "~0.7.1",
    "applicationinsights-js": "~1.0.20",
    "office-ui-fabric-react": "6.189.2",
    "react": "16.8.5",
    "react-custom-scrollbars": "~4.2.1",
    "react-dom": "16.8.5",
    "react-dotdotdot": "~1.2.3",
    "react-js-pagination": "~3.0.2",
    "ts-md5": "^1.2.4",
    "web-animations-js": "~2.3.1"
  },
  "devDependencies": {
    "@microsoft/rush-stack-compiler-3.3": "0.3.5",
    "@microsoft/sp-build-web": "1.10.0",
    "@microsoft/sp-module-interfaces": "1.10.0",
    "@microsoft/sp-tslint-rules": "1.10.0",
    "@microsoft/sp-webpart-workbench": "1.10.0",
    "@types/chai": "3.4.34",
    "@types/mocha": "2.2.38",
    "@voitanos/jest-preset-spfx-react16": "~1.1.0",
    "ajv": "~5.2.2",
    "concurrently": "^5.1.0",
    "gulp": "~3.9.1",
    "gulp-changed": "~3.2.0",
    "gulp-modify-file": "^1.0.1",
    "gulp-rename": "~1.2.2",
    "gulp-replace": "^1.0.0",
    "gulp-sass": "~4.0.1",
    "gulp-stripbom": "~1.0.4",
    "gulp-stylelint": "~8.0.0",
    "gulp-util": "~3.0.8",
    "gulp-wrap": "~0.13.0",
    "hard-source-webpack-plugin": "^0.13.1",
    "jest": "~23.6.0",
    "path-exists": "~3.0.0",
    "require-dir": "~0.3.2",
    "resx-to-ts-json": "~1.0.14",
    "run-sequence": "~2.2.1",
    "stylelint": "~9.9.0",
    "stylelint-config-standard": "~18.2.0",
    "stylelint-scss": "~3.4.0",
    "tfs-unlock": "~0.6.1",
    "through2": "~2.0.3",
    "tslint-microsoft-contrib": "~5.0.0",
    "webpack-bundle-analyzer": "~3.0.3",
    "yargs": "^15.1.0"
  },
  "resolutions": {
    "@types/react": "16.8.8",
    "@types/react-dom": "16.8.3",
    "@pnp/pnpjs": "~1.3.9",
    "@pnp/sp-taxonomy": "~1.3.9"
  }
}

Can you guys maybe give me a hint in the right direction? Many thanks in advance!

[pkmelee337]

After some more debugging into the SP file 'https://spoprod-a.akamaihd.net/files/sp-client/sp-pages-assembly_nl-nl_7d8940084e2739456a9a1d09ee6e4d6d.js' I found out that the error is indeed coming from one of my own files. It happens in components from my library (quite big, and created originally from this example) where I'm extending other components, so it seems it indeed has to do something with circular dependencies. I'm trying to implement some strategies like this one.

The crazy thing is that it is working when I'm ship bundling and packaging those files. (without serving them) I think it also has to do something with the react version, but I can't find the version spfx is hosting. When serving it uses the react version from my node_modules folder, which is 16.8.5.

[pkmelee337]

Allright, a few days later but I think I managed to fix the issue. It was indeed all about circular dependencies. Our library is quite big, so at first I really didn't know where to start. To give me a hunch in the right direction I used a few npm packages to find circular dependencies in my code. The one I liked the most is the circular-dependency-plugin. To use it in the spfx build process you could configure it like this:

build.configureWebpack.mergeConfig({
    additionalConfiguration: (generatedConfiguration) => {
        includeCircularDependenciesPlugin(generatedConfiguration.plugins);
        return generatedConfiguration;
    }
});
function includeCircularDependenciesPlugin(plugins) {
    plugins.push(new CircularDependencyPlugin({
        // exclude detection of files based on a RegExp
        exclude: /node_modules/,
        // add errors to webpack instead of warnings
        failOnError: true,
        // allow import cycles that include an asyncronous import,
        // e.g. via import(/* webpackMode: "weak" */ './file.js')
        allowAsyncCycles: false,
        // set the current working directory for displaying module paths
        cwd: process.cwd()
    }));
}

Another plugin I used was madge. Both plugins came up with the same results. The problem I had with these plugins is that I have a quite big folder structure and most folders have their own index.ts which exports the classes and interfaces I need up to a single point where everything comes together. But after all the plugins were seeing these index.ts files (which has imports from other classes also) as circular dependencies too (which off course makes sense). They did however bring me to the files where I really had a circular dependency.

The biggest help for me was the blog I described earlier. As said I already had an index.ts in almost every folder and was exporting my classes and interfaces up to a central point, but previously I didn't really care about the order of those imports in these files. After I fixed the real circular dependencies and put all the imports in the right order for each index.ts the error was fixed. The plugins do however still see the index.ts and imports from it as circular dependencies, but it's all about the loading order (perfectly explained in the blog). It did cost me a lot of time though and I hope I can help anyone with this information. :-)

If you every come across this error and got no idea in which file this is happening. I found out by debugging the sharepoint sp-pages-assembly_.js file. This file is minified, but with chrome for example you are able to pretty print this file. The real error occured in the following lines of code in the catch:

return e.loaderConfig.entryModuleId ? function(e, t) {
    return t.load(e).catch((function(r) {
        return b(e, e.loaderConfig.entryModuleId, [c.checkResourceUrl].concat(t.loadEntryPointErrorProcessors), (function() {
            return s.a.buildLoadEntryPointError(e, r)
        }
        ))
    }
    ))
}

[andrewconnell]

Cool... good to see its resolved. From your last comment, it appears to be specific to your project & not SPFx so I'm going to close this issue.

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues