3 ms·
The solution would be a node standard library project that contains the slowly moving parts of the 1500 dependencies, which means that it doesn't need too much
by xiphias2 8y ago
The solution would be a node standard library project that contains the slowly moving parts of the 1500 dependencies, which means that it doesn't need too much maintainence.
I don't understand why the companies that depend on webpack haven't built a project like this yet (and made sure that the important projects use that library), but I believe it's just a matter of time.
- baddox 8y agoThat’s a great way to have even more competing libraries. https://xkcd.com/927/ https://xkcd.com/927/
- xiphias2 8y agoWhere are those 15 efforts? I don't see any effort to take a hard look at combining the most used few hundred libraries into a collection of a few libraries. It's hard and boring work also.
- baddox 8y agoUnderscore and Lodash are obvious examples. I don't know if the project maintainers' stated purpose is specifically that, but they are clearly creating big libraries of common utilities. And, surprise surprise, two extremely common problems with frontend NPM projects are: 1) unintentionally importing the entire library instead of the few functions you use, and 2) having many different versions of the libraries in your output bundle because of other dependencies. Hence things like this exist: https://www.npmjs.com/package/babel-plugin-lodash https://www.npmjs.com/package/babel-plugin-lodash https://www.npmjs.com/package/lodash-webpack-plugin https://www.npmjs.com/package/lodash-webpack-plugin