Production Source Maps

[Rowno]

Is it possible to generate/serve separate source map files in production?

[albinekb]

Looks like #918 (comment) is an answer to your question?

[arunoda]

Thanks @albinekb that's it is.
But @Rowno exposing source maps into production is not a pretty good idea.

[Rowno]

I tried this config and ran NODE_ENV=production next build but no .map files were output.

module.exports = {
  webpack: config => {
    config.devtool = 'source-map'

    for (const r of config.module.rules) {
      if (r.loader === 'babel-loader') {
        r.options.sourceMaps = true
      }
    }

    return config
  }
}

Source maps in production make tools like Sentry far more useful.

[arunoda]

@Rowno we use inline-source-maps usually.
I've less experience on source-maps.
But anyway, I don't recommend exposing them for production.
But you can always tinker with the webpack config and what's going on and configure it.

[Rowno]

What's so bad about exposing them in production?

[albinekb]

You should upload them as a release to sentry instead @Rowno
See https://docs.sentry.io/clients/javascript/sourcemaps/#uploading-source-maps-to-sentry for more 👌

[Rowno]

I would if I could generate them. 😅 Looks like there's multiple things preventing them from working including Uglify.

[khrome83]

Can we reopen this issue? @arunoda

There is a valid use-case for having production source maps. Or at-least built as part of production code build. But we can strip before it is served.

1. The files that are bundled in webpack output are different depending on if you are in development or production.
2. Uploading .map files to sites like Rollbar, Airbrake, or Honeybadger is a common practice.

Currently we can achieve the follow -

• External Sourcemap on Development only
• Inline Sourcemap on Production only

We want to generate external source maps, but do not seem to have the capabilties with next.config.js to override the default npm run build settings.

Some help would be beneficial. Regardless what we do, the source maps are ignored within a production deploy of Next.

[khrome83]

Want to point out that we should do the following -

https://webpack.js.org/configuration/devtool/

hidden-source-map. This generates the external file but does not create the link to the file. This is exactly what needs to be supported.

[ethanresnick]

This is really important for me too.

Different users are going to want different kinds of sourcemaps (e.g., I actually don't want mine to be hidden—I'm not trying to obfuscate my code, and a linked sourcemap is by far the simplest way to get the file to Sentry), so I think a configuration option that lets the user provide a function returning the type of sourcemap to generate would be good. The default in Next could be something like:

({dev}) => dev ? 'inline-source-map' : 'false'

And a user who wants production source maps could just do:

({dev}) => dev ? 'inline-source-map' : 'source-map' // or 'hidden-source-map'

[khrome83]

@ethanresnick - Mostly agree. This is what we found out when we experimented.

1. Full source maps added enough to our download, that Google Page Speed insights lowered our score by 10 pts for desktop and mobile. Hence why hidden-source-map was the option we are recommending.

2. "simplest way to get the file to Sentry" - totally understand what your going through. We can get sourcemaps to Rollbar a lot easier by having them on the site. Turns out because of 1 above, we didn't feel this was a good idea. So as part of our CI pipeline we end up building them, then throwing them away and doing a normal build.

3. next.config.js does not have all the power over sourcemaps. Any changes we besides below make work well development, but fail with production builds. Looking at the source code, we decided to go a different route. The following snippet builds inline-sourcemaps only.

const webpack = require('webpack');

module.exports = {
  webpack: (config) => {
    if (!process.env.SOURCE_MAPS) {
      return config;
    }

    const configOptions = config;
    configOptions.devtool = 'source-map';
    configOptions.output.sourceMapFilename = '[file].map';

    // Perform customizations to config existing plugins
    for (const options of configOptions.plugins) {
      if (options instanceof webpack.optimize.UglifyJsPlugin) {
        options.sourceMap = true;
        break;
      }
    }

    return configOptions;
  },
};

We set the above up so it exits the custom config if we don't have SOURCE_MAPS set. This will generate inline-sourcemaps in production. We then wrote a custom script using:

npm install convert-source-maps --save-dev
npm install combine-source-maps --save-dev

Long story, we would scrape all JS files in ./next and ./next/bundles/pages for any inline sourcemaps, and pull them out. We then use convert & combine to create external files for the sourcemaps. Then we would upload to our Error Reporting suite.

We called all this code through a new and special NPM build command. Once it was done, we removed the .next/ folder and did a normal build to prepare for our deploy. We also "saved" build-stats.json & BUILD_ID to use for the second build, so everything would line up.

Long story short, this was a incredible amount of effort, and a total hack. Without changing how next handles production builds, this was the best option we had.

[Rowno]

I've gotten configurable production source maps working by making some changes to the next.js server and build process. I still have some tidy up to do but I'm hoping to submit a pull request in the next week or so.

Here's my work in progress: v3-beta...Rowno:production-source-maps

[khrome83]

@Rowno - some feedback - can you make it hidden-source-maps.

This does the same thing as source-maps, except it does not create a reference within the app.js file or page/ files.

This means your user will not download it, but you have it generated to uploaded to Sentry like @albinekb said above. My team uses Rollbar, and would greatly benefit from this.

Additionally, @arunoda - if we put a pull request in for this (GJ @Rowno), can we get this on the 2.4.x branch? My team can not switch over to 3.0.0 beta with our live site yet. We need to wait for that set of tags to stabilize. But we need sourcemaps ASAP.

We had a hack in to make them sort of work. But the 2.4.1 release broke that effort. We did not go as far as @Rowno to modify next itself.

[Rowno]

You can set it to whatever you want, I made it a config option. But the browser will only download external source maps if you have the DevTools open, so source-map should be fine.