This seems to be a bug with the chrome. Clicking on the relative source map links generated in the stack trace is not working. But if you remove the ./
before the file path, the links will work.
This link doesn't work: webpack-internal:///./src/pages/index.tsx
But this link works: webpack-internal:///src/pages/index.tsx
Also this link with absolute resource path works:
webpack-internal:///C:/myfolder/projects/gatsby/src/pages/index.tsx
How are these links generated?
The webpack-internal:///
links are generated using the moduleId. In the above link, the moduleId is ./src/pages/index.tsx
. There are several options to customize this moduleId in the webpack. Available options are: natural
, named
, deterministic
and size
.
Except the named
, the other options assigns numeric id's to the modules. The numeric links look like this: webpack-internal:///7220:124:9
. Clicking on these links also works.
But as you noticed they are not readable and not ideal for debugging.
So how to get readable working webpack links?
Looks like there is no straight forward option to customize the relative urls generated for the moduleId. But you can add a tiny custom webpack plugin to customize the relative url and get the working webpack-internal
links.
In Gatsby, you need to add this custom webpack config in the gatsby-node.js file.
const { DefinePlugin } = require(`webpack`)
class ProcessRelativeUrl {
constructor() {
this.plugin = new DefinePlugin({
PROCESS_RELATIVE_URL: JSON.stringify(`processrelativeurl`),
})
}
apply(compiler) {
compiler.hooks.compilation.tap('NamedModuleIdsPlugin', compilation => {
compilation.hooks.afterOptimizeModuleIds.tap('NamedModuleIdsPlugin', $modules => {
const chunkGraph = compilation.chunkGraph;
$modules.forEach(module => {
const moduleId = chunkGraph.getModuleId(module);
if (moduleId) {
// remove './' from the path
chunkGraph.setModuleId(module, moduleId.substr(2));
}
})
})
})
}
}
exports.onCreateWebpackConfig = ({ actions }) => {
actions.setWebpackConfig({
plugins: [new ProcessRelativeUrl()]
})
}