5 ms·

Is there a "distribution" bundle convention for npm ? Analogous to static linking, it would be one .js file that would bind all dependencies into a bundle (e.g.

Is there a "distribution" bundle convention for npm ? Analogous to static linking, it would be one .js file that would bind all dependencies into a bundle (e.g. gulp.dist.js) . In that case you would end up with a much smaller number of dependency files to manage.

Klathmon 10y ago
There is for your final output (meaning the stuff you would upload to the server and serve to the user). but not for the development. IMO it's a pretty big anti-pattern to do that. It just hides the problem of managing dependencies (see, it's not 10,000 files, it's just one!), but doesn't fix any of the issues associated with it. Keeping each dependency small, and having tons of them means that deduplication can work better, tree shaking works better, and it lets you do things like swapping out one package for another with the same API.
- currywurst 10y ago
  In this case, most of the files pulled down are the development dependencies which are not going to be exposed to the production code. I would be perfectly fine if npm pulled down "distribution" versions for tools like gulp, typescript et al
  - Klathmon 10y ago
    It might just be me living in a bubble, but I'd much rather have the full version downloaded to my machine in it's "raw" form than a "compiled" version. Even just for the ability to dive into the source i'm using if i'm debugging something, or be able to look at the actual code i'm running if I want to understand how a tool works. This is one of the reasons why I like how lodash handles their library. You can install the "regular" version of lodash and require it like "normal", or you can install a single big compiled lodash file, or you can install one that exports as ES6 modules, or you can install a single function at a time... Obviously every package can't afford to spend that much time on packaging, but a framework similar to that along with some changes to NPM to allow tagging a package as an "alias" of another (so lodash-as-one-big-file will be treated as lodash for other packages) would go a long way into making everyone happy.

Klathmon 10y ago

There is for your final output (meaning the stuff you would upload to the server and serve to the user). but not for the development. IMO it's a pretty big anti-pattern to do that. It just hides the problem of managing dependencies (see, it's not 10,000 files, it's just one!), but doesn't fix any of the issues associated with it. Keeping each dependency small, and having tons of them means that deduplication can work better, tree shaking works better, and it lets you do things like swapping out one package for another with the same API.

currywurst 10y ago
In this case, most of the files pulled down are the development dependencies which are not going to be exposed to the production code. I would be perfectly fine if npm pulled down "distribution" versions for tools like gulp, typescript et al
- Klathmon 10y ago
  It might just be me living in a bubble, but I'd much rather have the full version downloaded to my machine in it's "raw" form than a "compiled" version. Even just for the ability to dive into the source i'm using if i'm debugging something, or be able to look at the actual code i'm running if I want to understand how a tool works. This is one of the reasons why I like how lodash handles their library. You can install the "regular" version of lodash and require it like "normal", or you can install a single big compiled lodash file, or you can install one that exports as ES6 modules, or you can install a single function at a time... Obviously every package can't afford to spend that much time on packaging, but a framework similar to that along with some changes to NPM to allow tagging a package as an "alias" of another (so lodash-as-one-big-file will be treated as lodash for other packages) would go a long way into making everyone happy.