Turn on source maps by default (for dev + production)

[addyosmani]

Feature request

tl;dr: Can we please turn source map generation on for dev and production? :)

Is your feature request related to a problem? Please describe.

As of #943, Next.js does not output source maps by default. This is wee bit inconsistent with other popular React tooling such as CRA, which do output maps without developer opt-in when you npm run build or npm run start. I would like Next to consider changing this behavior to align with developer expectations of React scaffolding tooling.

Overall, despite some discussion of shortcomings (e.g facebook/create-react-app#139), the CRA community appears to have found more value keeping source maps enabled than not. Preact CLI also outputs source maps by default in dev and prod builds.

Describe the solution you'd like

I would like Next.js to switch on source map generation for dev and production by default.

Reasons to turn them on:

• Bundle analysis tooling (like webpack-bundle-analyzer or source-map-explorer) require source maps in order for developers to dive into why their bundles may be bloated. Without this turned on, developers need to do additional work to take advantage of these tools.
• Browsers like Chrome are starting to explore adding audits for opportunities to optimize what is in your bundle via Lighthouse (requires source maps) and improved debugging via DevTools if we know the structure of your application (also requires source maps)
• It should be trivial for developers to disable source maps via DevTools during their developer iteration workflow if they want them unmapped for debugging.

Describe alternatives you've considered

An alternative to turning on source maps by default is a docs change where we just encourage more developers to opt into using source maps for dev and prod. I don't believe this will lead to as many developers getting the full advantages of having source maps turned on however... :)

cc @developit in case he has further input

[timneutkens]

My main concern here would be increasing build time, it'd be great to get insight into how much it's affected.

[richardwillars]

My concern is around sourcemaps in production.. it's essentially making your sourcecode available and readable to all. I would prefer to have them enabled on our dev and qa environments but turned off on production. We can then still perform lighthouse audits etc on those environments

[airtonix]

your sourcecode is already up there in production. all you're doing with this line of thinking is making it harder than it needs to be for debugging problems in production.

[Akshay2996]

My concern is how it impacts the User experience since the it will take longer to download JS code on the client because source maps are enabled in production. What do you think?

[tweeres04]

Source maps are only downloaded if the devtools are open

[addyosmani]

I think there's still value developer tooling can gleam from dev-time source maps, but this is of course limited due to how often a production step can strip out library code that's really only there for your iteration workflow (think debugging helpers).

Perhaps there's a sweetspot we can land on. One option is builds generate a production source map which can be used by developer insight tooling, but .map files are just not deployed to prod servers?

[housseindjirdeh]

With regards to build times (cached production builds):

	Without source maps	With source maps
Basic 2 page example	11s	13s
geo.data.gouv.fr	13s	23s
zeit.co	15 min	?

Retrieved these numbers while using next-source-maps. I used version 0.0.4-canary.1 which generates both client and server maps.

With regards to whether source maps should be used in production, I agree that there might be things that are missed if they are only enabled during dev/qa environments. A build that generates production source maps that can be analyzed via tooling with the option of deploying them to prod servers (which I would prefer to be the default similar to CRA) sounds like a nice middle-ground.

[housseindjirdeh]

I've written some thoughts regarding how we can approach source maps in this doc.

[airtonix]

should have just posted that information here tbh

[kylemh]

Curious to know if this will be a permanent RFC or if anybody in Zeit sees value in this?

[timneutkens]

Define "permanent RFC". It's being investigated. As you can see when sourcemaps get enabled build times almost double in many cases, making it really tricky as a default.

[kylemh]

That's exactly the kind of info I wanted to hear after the numbers were shared! Thanks.

Maybe there's a compromise in terms of offering it as part of config as opposed to a plugin?

I'm okay with the increased build-time, for example.

[anthanh]

Hey, we are facing the same problem trying to have Sentry configured as suggested here, but with a production build.
Having source maps would be useful in order to understand and debug errors/warns in production environments.
I'm also okay with the increased build-time, debugging time is also important 😅.

[Andy671]

@anthanh , Have you managed to add the Sentry debugging to the production project?

[jooj123]

The fact that we cant enable source maps for production to diagnose issues is a big issue.
We dont have any concerns about build time or exposing client code to public (all sensitive code is server side anyway)

This plugin doesnt seem to work either for me: https://github.com/zeit/next-plugins/tree/master/packages/next-source-maps

Debugging errors on client such as:

at value line 1, column 17847 (mydomain/_next/static/chunks/1aa2bad629f3a528741241dd181fa9de64462cd7.0fc01c85f71f40e422d2.js:1)
at ? line 1, column 15374 (mydomain/_next/static/chunks/1aa2bad629f3a528741241dd181fa9de64462cd7.0fc01c85f71f40e422d2.js:1)
at initializePromise line , column ([native code]:0)
at Promise line , column ([native code]:0)
at n line 1, column 1934 (mydomain/_next/static/chunks/commons.81c26814c57528f74740.js:1)
at value line 1, column 15146 (mydomain/_next/static/chunks/1aa2bad629f3a528741241dd181fa9de64462cd7.0fc01c85f71f40e422d2.js:1)
at ? line 1, column 13316 (mydomain/_next/static/chunks/1aa2bad629f3a528741241dd181fa9de64462cd7.0fc01c85f71f40e422d2.js:1)

Without a proper stack trace etc is very difficult (source maps would be a massive help)

[hems]

indeed it's very important and necessary to have source maps in all stages, during development, on the staging environment and also in production.

as pointed out here debugging time is very important also I believe most users expect it to be turned on by default, at least me and every developer I know would expect that to happen from such incredible framework.

most users have small projects so taking zeit.co as example of build time is unfair to the community specially new comer who are just starting to develop, if build time becomes a problem people can opt out.

There are so many things on the documentation, having one page about how to optimise build time and any other kinds of optimisations would actually be more useful and productive than assuming people won't mind not having source maps on their project in 2020.

[kachkaev]

With Sentry example shows how to enable source maps in production, but only for token bearers. IMHO all we need is two new configuration params built into the core.

1. Defines if source maps are generated at all (off by default for BC and for performance reasons)
2. Optional token or a header check function for production source maps

The second parameter can produce a custom API route behind the scence, i.e it will work when target is a Node.js server or Lambda fns (now.sh).

[addyosmani]

@timneutkens @rauchg I wonder if there's an incremental path we can take here...

I like @housseindjirdeh's option 3 proposal of including source maps by default but requiring the developer to enable it themselves via next.config.js (so: lower barrier of use, but don't impact build times for everyone)

// next.config.js
module.exports = {
  options: {
    sourcemaps: 'production' // possible values can be production, development, or none
  }
}

[timneutkens]

Yep, I'm planning to add something like that soon. Currently working on finishing up a conference talk and will add it after that.

[shobhitsharma]

@timneutkens Is there any example of typescript sourcemaps within monorepo? (without using next-transpile-modules)

[vitorhsb]

Hey @timneutkens , will this ever be out of experimental feature and set into a proper config prop similar to what @addyosmani has mentioned above?

The following warning message have already been spotted by our devops team and questions have been asked.

warn  - You have enabled experimental feature(s).
warn  - Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use them at your own risk.

It would be great if we use it as an option in next.config.js and remove the warning message, since this is the only experimental feature we are currently using.

[jasonwilliams]

Sourcemaps can be used server side in production too for NodeJS. I created an issue for it here:
#20096

[rbabayoff]

hey, any news on this?

[paambaati]

This has just moved out of experimental status (see #20267) and should land in the next canary version!

[souvikbasu]

Stumbled upon this discussion in 2023. If anybody came to this page through search engine and is still looking for generating sourcemaps for prod, this nextjs doc might be helpful: https://nextjs.org/docs/advanced-features/source-maps. Not sure, if there is a easy way to skip deploying the generated sourcemaps in prod

[rubendinho]

But js there a way to disable them from being deployed? I think a common use case here is that you build the source maps, upload them to your error reporting service during build and then delete / don't deploy them.

I think this question issue would be complete if we had a definitive answer.

[uhhhsoyan]

@rubendinho that's the use case I'm interested in. Did you figure out how to generate the source maps without deploying them?

[dorji-dev]

@rubendinho Kindly tag me in the comment if you have found a way for the given use case i.e. only generate source maps for error reporting services and delete/ don't deploy after.

[airtonix]

@uhhhsoyan @dorji-dev I'd have thought that you do exactly that:

• decide that you want your production debug life to be horrible
• make a prod build
• find ./your-dist-dir/ -type f -name "*.map" -delete
• magical upload command

did I miss something?

[atstoyanov]

@airtonix I'm using this approach, but the reference in the .js file is left and some browsers (Safari) are putting 404 errors in the console.
Web pack supports hidden-source-map flag which enables the source map generation, but doesn't include the reference in to the build. So the source maps can be used for error reporting (like datadog) and not served on the prod server.

[0x1bitcrack3r]

This config https://nextjs.org/docs/advanced-features/source-maps will work if you use next start What if you use a custom server like node node server.js it just serves all the static chunk files. If someone can provide a way to get a stack trace from a custom server like node, I highly appreciate your help.

reference: https://nextjs.org/docs/pages/building-your-application/configuring/custom-server

[0x1bitcrack3r]

Hi Everyone, here is the PoC repo that I have created https://github.com/0x1bitcrack3r/next-node-elk on how to get stack-trace and sourcemap from the webpack generated chunk files.