Remove sourcemaps and lib/ from shipped package

[ptomato]

Credit to @43081j for the suggestion. It seems that many packages these days are choosing not to ship sourcemaps. Even though they don't get shipped to the web regardless and don't affect end users, they do increase on-disk size and bandwidth usage for the majority of developers who will never need to debug the polyfill. Especially if multiple versions of the polyfill are used across multiple projects, or if a project's CI doesn't cache downloads.

The only thing that refers to the TypeScript files in lib/ is the sourcemaps, so if we didn't ship sourcemaps we could also drop lib/ from the package.

The workaround if a developer does need sourcemaps is to clone the repo locally, then use npm link to use the local repo as a dependency, and edit the local rollup.config.js to enable sourcemaps. (Or we could do something like disabling sourcemaps if NODE_ENV is production)

[justingrant]

Not sure you know this, but before I joined the Temporal champions I had already been on a multi-year crusade to have package maintainers add sourcemaps. :-)

Given that history, unsurprisingly I'm not in favor of removing sourcemaps, because it makes debugging into transpiled code (especially as it's minified, as our package is) incredibly difficult.

More context:

• Use sourcemap sources for Go to Implementation and show them in Explorer pane (like Chrome devtools does), even when no debug session is active microsoft/TypeScript#53723
• Address concerns from package maintainers that sourcemaps are too large tc39/ecma426#41
• Include working sourcemaps in dist fullcalendar/fullcalendar#4719 (comment)

for the majority of developers who will never need to debug the polyfill

Although it's unlikely that any one developer in any one debug session needs to debug this polyfill, the chance that developers need to debug into *some* package is very large, and it's impossible for package maintainers or package users to know in advance which packages will need debugging. FWIW, I've never built any non-trivial app that didn't require debugging into library code, and I assume my experience is not unusual. Like picking up trash, sourcemaps are most helpful if every package does it.

Most of the requests I hear to remove sourcemaps (see first link above for a summary and links) come from advanced developers and package maintainers. But the vast majority of JS developers are IDE-using non-experts who rely on IDE and/or dev-tools GUI debuggers, and for them being able to seamless debug into library source is a huge DX benefit that IMO vastly outweighs the concerns of advanced developers.

The workaround if a developer does need sourcemaps is to clone the repo locally, then use npm link to use the local repo as a dependency, and edit the local rollup.config.js to enable sourcemaps.

These sound like steps that 80%+ of JS developers will not know how to do. If advanced developers are really excited to remove sourcemaps, they can do this via build steps, post-install scripts, and other advanced-developer fu.

[43081j]

shipping sourcemaps isn't the answer.

you're in the minority here as a person who wants to debug this module. most consumers will never do such a thing, and because of your personal preference as an engineer more likely to debug things, everyone else pays the cost.

i don't think you realise how few people debug node modules in the wild, especially given Chrome now ignores them by default in dev tools.

by shipping sourcemaps, you're often doubling the package size for consumers and CI to download. alone, this isn't a huge cost, but in a deep dependency tree this can be a huge cost. we've seen dependency trees go from pulling down ~1GB of install size to ~200MB, which arguably far outweighs your need to debug things.

particularly in the e18e side of things im leading, many, many packages have dropped sourcemaps over the last year or so. unfortunately an equal (or larger) crusade has been going on to do the reverse of yours.

longer term, the answer is that you should be able to pull sourcemaps from somewhere when needed rather than shipping them with the source. i've raised this discussion with the sourcemaps tc39 group but there's no solution yet and won't be for some time.

at least in our community, people are unlikely to migrate to this polyfill when they see that only 129KB of the 3MB is the polyfill itself (the rest is sourcemaps, unused files and umd/cjs bundles)

my suggestion:

if you can't be convinced that the majority don't need these sourcemaps, get rid of them anyway and stop minifying the source. you're more than capable of debugging a non-minified bundle (as are most developers). that'll drop 1MB+ of the package and you can still happily debug whatever you like.