Next.js: Source map error: Error: Invalid URL: (Firefox)

[jasonwilliams]

Bug report

Navigating to our next.js page in Firefox we recieve the following error in the console:

Source map error: Error: Invalid URL: webpack://[name]_[chunkhash]/webpack/bootstrap
Resource URL: http://127.0.0.1:3001/_next/static/development/dll/dll_01ec57fc9b90d43b98a8.js?ts=1574263926643
Source Map URL: dll_01ec57fc9b90d43b98a8.js.map

When investigating the file itself i do see a lot of webpack://[name]_[chunkhash] here are the first few lines: (Im guessing it shouldn't be like this?)

{"version":3,"file":"dll_01ec57fc9b90d43b98a8.js","sources":["webpack://[name]_[chunkhash]/webpack/bootstrap","webpack://[name]_[chunkhash]/./node_modules/object-assign/index.js","webpack://[name]_[chunkhash]/./node_modules/prop-types/checkPropTypes.js","webpack://[name]_[chunkhash]/./node_modules/prop-types/lib/ReactPropTypesSecret.js","webpack://[name]_[chunkhash]/./node_modules/react-dom/cjs/react-dom.development.js","webpack://[name]_[chunkhash]/./node_modules/react-dom/index.js","webpack://[name]_[chunkhash]/./node_modules/react/cjs/react.development.js","webpack://[name]_[chunkhash]/./node_modules/react/index.js","webpack://[name]_[chunkhash]/./node_modules/scheduler/cjs/scheduler-tracing.development.js","webpack://[name]_[chunkhash]/./node_modules/scheduler/cjs/scheduler.development.js","webpack://[name]_[chunkhash]/./node_modules/scheduler/index.js","webpack://[name]_[chunkhash]/./node_modules/scheduler/tracing.js"],"sourcesContent":[" \t// The module cache\n \tvar installedModules = {};\n\n \t// The require function\n \tfunction __webpack_require__(moduleId) {\n\n \t\t// Check if module is in cache\n \t\tif(installedModules

To Reproduce

• Run next watch
• Navigate to next in Firefox
• Open dev tools

Screenshots

System information

• OS: MacOS 10.14.6
• Browser: Firefox Developer Edition (71.0b10)
• Version of Next.js: 9.1.3

Additional context

This only seems to be affecting Firefox, Chrome reports no issues in the console

[jasonLaster]

@jasonwilliams does this happen for a publicly available project I can pull down and test?

[jasonLaster]

CC @loganfsmyth this looks like a URL.

I remember we're stricter than chrome. Do you know what might be going on here?

In someways, this seems reasonable. the URL is pretty weird and probably invalid and it is reasonable to report that. I suppose we could also opt to be silent and show the error in the debugger UI... like a warning icon in the debugger editor footer.

[jasonwilliams]

@jasonLaster yes it does i can reproduce this in the next.js examples:

Steps

• Checkout next.js (i checked out master - d90c85311140b8a55d611dd5cc4fd15e30f7e708)
• in the vscode directory, add a launch.json file with this content https://gist.github.com/jasonwilliams/417920a7bb231e853c6e0521621c4e3d
• Navigate to examples/blog-starter
• npm install in this directory.
• npm run dev
• In VSCode launch debugger "Firefox - NextJS"
• Once firefox is opened, look in the dev tools console

[loganfsmyth]

Given the sources values, I think this error is expected, because webpack://[name]_[chunkhash]/webpack/bootstrap is indeed an invalid URL. Since it is ://, the value after it is a hostname, e.g. mozilla.com or whatever. URLs define a initial [ at the beginning to indicate a URL that is an IPv6 address, e.g. webpack://[1::1]. Given that name and chunkhash here are clearly a bug, let's move on to that:

This seems to be either a bug in https://github.com/asfktz/autodll-webpack-plugin, which Next is using, or a bug in Webpack itself. autodll creates DLLs with a global library with "[name]_[chunkhash]" as the name of the DLL and the name of the library.

I'm _guessing_ it's the second one that's the problem, though it's hard to tell. The docs for DllPlugin's name argument say it accepts template replacements for [name] and [hash] (though I think [chunkhash] is probably also assumed to work there?). However, the docs for output.library make no such mention. And since sourcemaps are generated using output.devtoolModuleFilenameTemplate's default of webpack://[namespace]/[resource-path]?[loaders] and those same docs say [namespace] is "The modules namespace. This is usually the library name when building as a library, empty otherwise", it sounds like autodll is expecting Webpack to place [name] and [chunkhash] in the library name whereas Webpack's docs don't suggest that it is supposed to do that.

[jasonLaster]

cc @Timer I wonder if you have more context here.

[jasonwilliams]

Also cc @asfktz

[jasonwilliams]

It is true that static/development/dll.dll_***.map/ is spitting out bad sourcemap paths

[jasonwilliams]

Up to date reproduction steps:

• VSCode (v1.41.1)
• Make sure you have the "Debugger for Firefox" (im using 2.6.1)
• Check out https://github.com/jasonwilliams/nextjs9-typescript-server-vscode-example @ 315318e21619f16f09e593b8b255e45de1a66a7b
• npm install
• npm run-script dev

You should see :

[jasonwilliams]

https://github.com/asfktz/autodll-webpack-plugin looks to be deprecated and is recommending https://github.com/mzgoddard/hard-source-webpack-plugin until Webpack 5.0 comes out

[jasonwilliams]

This issue will go away in webpack 5 which is being looked at https://github.com/zeit/next.js/issues/9426#issuecomment-593555575 module federation will be replacing the dlls

[oyeanuj]

@Timer @tim Also seeing this issue on a new project we are starting with Next. Is there a workaround as this seems like a production-stopping issue?

@jasonwilliams Did you end up with a workaround?

FWIW, here is my next.config.js
```js
const path = require( "path" )
const withFonts = require( "next-fonts" )
const withCSS = require( "@zeit/next-css" )
const withPlugins = require( "next-compose-plugins" )

const withBundleAnalyzer = require( "@next/bundle-analyzer" )({
enabled: process.env.ANALYZE === "true",
})

const nextConfig = {
webpack: ( config ) => {
config.resolve.alias["~"] = path.resolve( __dirname )
return config
},
}

module.exports = withPlugins([
withBundleAnalyzer,
withFonts,
withCSS,
], nextConfig )

[oyeanuj]

@jasonLaster @loganfsmyth Any updates/workaround from the Mozilla's side here?

[jasonwilliams]

@oyeanuj i only ever came across this issue when using the Firefox debugger, and they fixed it on their side by adding the path mapping as a default https://github.com/firefox-devtools/vscode-firefox-debug/issues/177#issuecomment-591005586 commit is here https://github.com/firefox-devtools/vscode-firefox-debug/commit/caeb6ba011775d7ac871e38df6ac9a0a0d71271c

Did you want to describe a bit more your browser and how you’re getting the issue?

[chrisbenincasa]

I've been hitting this issue in the Firefox dev console (not while using vscode for debugging). Is there guidance on fixing the mappings there?

[Timer]

This bug should be resolved on Next.js' canary channel (next@canary), could you please try and confirm?

[jasonwilliams]

@Timer Out of interest how was this fixed? Can you link to a PR?

[Timer]

We dropped autodll-webpack-plugin and switched to a Firefox-preferred devtool option. These changes were made over multiple PRs so it'd be hard to track down exact links.

[Timer]

Closing as I assume you've confirmed this as fixed for you. Please let me know if you still have problems!