search

ljharb / js-traverse

MIT License
45 stars 8 forks source link

0.6.9 introduces 3.7 Mb of dependencies #8

Closed chrisjameslennon closed 3 months ago

chrisjameslennon commented 4 months ago

Hi there, I was troubleshooting a large increase in my deployment size and have narrowed this down to the traverse 0.6.9 release With this new release:

Are they really needed?

Just a question as someone who is relying on this package (I know its not version one yet) :-)

ljharb commented 4 months ago

The number of files in node_modules, and their disk size, aren't really relevant - on a server, disk space is infinite and free, and for a browser, it only matters what ends up in your bundle.

As for the specific dependencies, they're necessary for robustness - in particular, properly identifying builtins cross-realm (like typed arrays). I believe they were added in v0.6.8.

ematipico commented 1 month ago

The number of files in node_modules, and their disk size, aren't really relevant - on a server, disk space is infinite and free

I would argue that this could inflate the cache in CI (in case people cache their node_modules or pnpm global store). And that cache isn't free, and people might need to pay more or frequently purge old caches.

VandeurenGlenn commented 1 month ago

The number of files in node_modules, and their disk size, aren't really relevant - on a server, disk space is infinite and free, and for a browser, it only matters what ends up in your bundle.

As for the specific dependencies, they're necessary for robustness - in particular, properly identifying builtins cross-realm (like typed arrays). I believe they were added in v0.6.8.

On a server disk space is infinite and free? That's the stupidest thing I ever heard. Nothing in life is infinite and free.

ttdatt commented 1 month ago

The number of files in node_modules, and their disk size, aren't really relevant - on a server, disk space is infinite and free, and for a browser, it only matters what ends up in your bundle. As for the specific dependencies, they're necessary for robustness - in particular, properly identifying builtins cross-realm (like typed arrays). I believe they were added in v0.6.8.

On a server disk space is infinite and free? That's the stupidest thing I ever heard. Nothing in life is infinite and free.

Yes, nothing is free, including @ljharb's effort. I don't like what he did, but don't throw out garbage takes like this

romainmenke commented 1 month ago

Please read : https://www.w3.org/2001/tag/doc/polyfills/#consider-whether-to-include-polyfills

Chasing robustness is not an absolute good. If a tool works for 99.9% of all users then we should not make changes that negatively affect the 99.9% for the good of .1%. (the numbers are made up, but you get the point).

I really hope we can reverse this path you are on @ljharb.

We should empower users with better tools to ensure robustness on their exotic environments. We should not force this mess of dependencies onto everyone.

I do think it is valuable if users with specific runtime constraints can use packages like this, but there are other ways. Options that do not negatively affect the extremely large majority.

As the maintainer of postcss-preset-env and polyfill-library (not the shit that got sold) I am deeply aware of the tradeoffs being made here and I do not agree with the path you have chosen.