Adding `sideEffects: false` to package.json

[neoncube2]

Hello! :)

Would it make sense to add sideEffects: false to package.json? This can enable more tree-shaking, in some cases: https://github.com/webpack/webpack/blob/main/examples/side-effects/README.md

axios, which (indirectly) depends on this package, has already added this flag: axios/axios#5025

[ericmorand]

Out of curiosity, what would be the point? mime-types package doesn't gave side effects, what would adding this information to the package manifest bring?

[neoncube2]

I'm not totally sure, but let's say that someone writes this code:

import mimeScore from 'mime-types/mimeScore.js';

I think that currently, webpack has to parse both mimeScore.js and index.js, because if these files contain side effects, they need to be included in the outputted code. For example, if index.js had a top-level statement that said window.location = 'https://example.com', then I guess that according to spec, this would need to be included in the code that webpack outputs.

Adding "sideEffects": false to package.json tells Webpack that none of the files in this package contain side effects, so it can only parse files that code is included from.

[neoncube2]

I found another reason for adding this flag, which is that Webpack usually only removes unused imports if the package that they're from has "sideEffects": false: eugenezinovyev/react-fontawesome-svg-icon#36 (comment)

[ericmorand]

My opinion is that it is an issue with Webpack. They should not enforce every single package in the world to add a non-official attribute to their paclage manifest because they decided, arbitrarily, to assume that packages have side effects by default. Other bundlers don't assume as much - and treeshake very efficiently - so this is an issue only with Webpack, and something they need to address.

[neoncube2]

Ah, but it's not Webpack that decided that packages have side effects by default... that's the way the EcmaScript spec is written! :)

I feel your pain on modules having to add this flag, though.

A better solution would be if Webpack (and other bundlers) could statically determine whether a package was side effect free or not, but my understand is that that's very difficult, given JavaScript's dynamic nature. Webpack does try to do this, but in cases where it fails, it's nice to have the sideEffects flag as an override.