Allow disabling server source maps locally

[alex-statsig]

Goals

Reduce high memory overhead in development when server modules are repeatedly recompiled (for no real reason, see #45204) and held in memory

Non-Goals

No response

Background

I've observed during memory profiling that many duplicated copies of source maps appear in memory profiler. In my case, the memory held for a single API route is 60MB. This is duplicated multiple times as the API route is recompiled in development, per API route, leading to an eventual OOM not long after.

""use strict";
/*
 * ATTENTION: An "eval-source-map" devtool has been used.
 * This devtool is neither made for production nor for readable output files.
 * It uses "eval()" calls to create a separate source file with attached SourceMaps in the browser devtools.
 * If you are trying to read the output file, select a different devtool (https://webpack.js.org/configuration/devtool/)
 * or disable the default devtool with "devtool: false".
 * If you are looking for production-ready output files, see mode: "production" (https://webpack.js.org/configuration/mode/).
 */
(() => {
var exports = {};
exports.id = "pages/api/graphql";
exports.ids = ["pages/api/graphql"];
exports.modules = {
...

Proposal

There could be a next.config option to disable the maps.

Additionally I've tried manually setting webpack.devtool and got "Warning: Reverting webpack devtool to 'eval-source-map'. Changing the webpack devtool in development mode will cause severe performance regressions.".

[j23schoen]

hey @alex-statsig have you found any ways to fix this? I'm experiencing the same thing locally. My heap snapshot has up to 200mb in just the (string) entry and I haven't found a way to fix it

[alex-statsig]

I have not overall. I was able to track down the source of our duplication at least which helped a lot. We were adding some listeners / setting some intervals on module imports / otherwise closure-leaking the module in really hard-to-spot ways. Next.js doesn't provide great ways to manage this cleanup (I think because the assumption is a serverless backend setup), but was able to track these down with some memory profiling dominator trees and ensure they got cleaned up or ran in a way that didnt leak scope.