Gatsby: v2 - Don't generate source maps by default

[tomazy]

Description

Gatsby by default generates very expressive source maps. They include the full, non-minified source code of the site, including all comments like TODO, etc. They also expose absolute paths to the project directory leaking things like user names and naming conventions.

Source maps in general should not be available to anyone willing to open the dev tools in their browser. Access to them should be restricted and this requires some additional adjustments on the web server level.

I suggest we disable the default source map generation in the next version of the project.

See: https://github.com/gatsbyjs/gatsby/issues/3324#issuecomment-361401512

[monsieurnebo]

Agreed! A nice way of managing sourcemaps could be a config parameter, such as:

// gatsby-config.js

module.exports = {

  pathPrefix : "/blog",
  sourceMaps : true,
  // ...

}

It would let users choose when and where use them and would be particulary useful on multi-environments development (develop, staging, etc...).

[jquense]

I don't think not generating source maps the right approach. For every production app I've made we've wanted them either to load when devtools were opened or to upload to sentry for clearer error tracking. I think if you don't want them in your uploaded site that's more of publishing concern than a building on?

[KyleAMathews]

Instead of disabling sourcemaps by default — how about instead we a) investigate using relative paths, removing comments and otherwise making them more tidy by default and b) add a plugin to easily disable producing source maps by modifying the webpack config which also conveniently would speed up builds some.

[monsieurnebo]

@KyleAMathews I cannot see the advantage of a plugin instead of a basic gatsby-config parameter? 🤔

[KyleAMathews]

@monsieurnebo mainly because we avoid config options at (almost) all costs :-)

Adding config is a much weightier decision vs. a plugin. Also plugins are much more flexible than config.

[monsieurnebo]

@KyleAMathews Ok! Would this plugin's purpose be only to disable sourcemaps via webpack configuration? Isn't that a bit overkill?

[KyleAMathews]

@monsieurnebo that's how a config option would work so it's the same thing

[siakaramalegos]

I'm struggling how to disable source maps for production since the default Webpack set up is to leave out the devtool option, but Gatsby v2 is enabling it. If someone has found a way to disable them for production, I would love to know how until either a setting or a plugin is created. I've tried coming up with a way based on the old version and the new docs, but it doesn't work:

// gatsby-node.js
exports.onCreateWebpackConfig = ({ actions, stage }) => {
  if (stage === 'build-javascript') {
    // turn off source-maps
    actions.setWebpackConfig({
      devtool: false
    })
  }
};

edit: added an SO question here

[siakaramalegos]

So it looks like that might actually work. Either my finder wasn't refreshing the file list or the /public/folder was holding on to old sourcemap files.

[github0013]

This solved removing source map in v2.
https://github.com/gatsbyjs/gatsby/issues/6289

yarn add gatsby-plugin-no-sourcemaps@next

  plugins: [
    "gatsby-plugin-no-sourcemaps",
  ]

[BillyWM]

Neither is working for me. workbox, used by gatsby-plugin-offline is still generating maps for all its files, so apparently all parts in the pipeline don't necessarily respect this setting.

(I did an rm -rf public && gatsby build. This isn't a problem of lingering files. It's definitely regenerating them)

edit: I guess the workbox-build dependency just comes this way.

[gatsbot[bot]]

Old issues will be closed after 30 days of inactivity. This issue has been quiet for 20 days and is being marked as stale. Reply here or add the label "not stale" to keep this issue open!

[gatsbot[bot]]

This issue is being closed due to inactivity. Is this a mistake? Please re-open this issue or create a new issue.

[j127]

I think having sourcemaps on by default in production is dangerous. There must be countless people out there who think their code comments, environment variable names, and source code are private because the output was minified, without realizing that everything is public. It seems like a security/privacy risk, because most people will assume that only the compiled version will be visible in production.