9 ms·

If you write JavaScript tools or libraries, bundle your code before publishing

48 points by callumlocke 11y ago

bryanrasmussen 11y ago
Ok, this finally gave me a use case for webpack as opposed to gulp that I could appreciate, but then it introduced two new potential competitors in Rollup and JSPM, so there's still extra stuff to keep up with. anyway I guess until it becomes industry practice to bundle everything I need to bundle stuff by myself that I will be using just to avoid this situation in the future (until it's fixed, but really I think bundle it all yourself sounds much more secure)
- netcraft 11y ago
  npm stats jspm 115,692 downloads in the last month rollup 95,038 downloads in the last month webpack 1,407,499 downloads in the last month jspm I believe had a good thing going for a while but webpack has well and truly replaced them now.
  - callumlocke 11y ago
    you missed the biggest one: browserify 2,218,006 downloads in the last month But my prediction is Rollup will take off in a big way at some point in the next 2 years. It's not quite stable enough yet, but it's just fundamentally better designed than everything else. Rollup is the only tool I'm aware of that properly exploits static analysis of ES6 module syntax. Every other bundler is full of hacks and moving parts, Rollup's codebase is clean and beautiful. It's already very good for bundling ES6 modular code, it's just still got some kinks when it comes to integrating people's CommonJS code. And I guess not enough people are actually using module syntax yet for Rollup to come into its own, which is a chicken and egg problem. It will get there though. Until Rollup is stable enough, I recommend Browserify. In my opinion Webpack and JSPM both try to do too much and are too prescriptive about workflow. My team switched from Browserify to Webpack a few months ago, and I now find it a bit suffocating and slow.
    - maattdd 11y ago
      Webpack v2 also tries to use the static part of es6 modules (for DCE ?)
      - lollipop25 11y ago
        Yes, Webpack is also trying out "tree shaking" https://github.com/webpack/webpack/tree/master/examples/harmony-unused https://github.com/webpack/webpack/tree/master/examples/harm...
GoBelle 11y ago
best thing I've read all week
wrong_variable 11y ago
Leaving aside all the advertisement and marketing. JSPM -> sounds like a good idea until you try using it, and SystemJS is just sad. Its not the fault of the specs, its just that the creator is having difficulty with funding - as with any other good open source projects. Webpack -> Slow, unstable and documentation is incomplete. RollUp -> I am not going to listen to the author's comment on how awesome his product is -_- I still think browserify is the only bundler out there that is sort of stablish. I locked my browserify@4.0.0 for 3 years and recently moved on to browserify@9.0.0 Being in the JS world you need to be conservative these days - especially if you want to ship in time.
- lollipop25 11y ago
  No one also cares if you think browserify is awesome. Everyone has their favorites, deal with it.
Ralfp 11y ago
Is Browserify falling out of favor? I've only just recently started to bundle my stuff with it instead of gulp's concat.
- callumlocke 11y ago
  No, Browserify is still quietly way out in front of everything else (in terms of npm downloads).
pokstad 11y ago
Also, can someone tell iOS libraries to stop relying on Cocoapods? After the github disaster, it should be standard to bundle dependencies.
joewood1972 11y ago
No, de-duplication and conflict resolution is much harder if dependencies are in a bundle. There are many better solutions to this problem: * Fix NPM and make it immutable. If there's a legal problem allow a package to be flagged with a warning and redirected to its new name. * Use bundleDependencies in npm * and maybe even back-up your entire code directory
joeframbach 11y ago
Can someone clarify what would happen in this scenario: - My app requires React. - My app also requires FooBarComponent whose dist is just a giant index.js which includes its own copy of React. - Now I get a bunch of errors because FooBarComponent and MyApp can't share anything between themselves. React really doesn't like it when two copies are running.
- exogen 11y ago
  FooBarComponent shouldn't have been packaged that way (it can include such a dist file for some people to use, but the npm package shouldn't export that). The typical way is for it to not include React as a `dependency` at all but a `peerDependency`. Then everything will be importing the same instance.
  - joeframbach 11y ago
    > (it can include such a dist file for some people to use, but the npm package shouldn't export that) I think that is exactly what the article is suggesting we do.
- lollipop25 11y ago
  The root of the problem is why FooBarComponent is a giant index.js. Also, why does it have React bundled if it expects to be a reusable component? Also, frameworks like React etc. shouldn't be a bundled dependency. They should be an external dependency or a top-level dependency.
jessaustin 11y ago
Ugh, no. Bundling should be done at the very end, when you're trying to build maintainable software. It's a mistake to bundle in the middle, because then even loosely-dependent modules will be limited to updating only when every intermediate dependency updates. Don't take these decisions out of the hands of the coders who are actually coding software.
- lollipop25 11y ago
  Are you aware that jQuery bundles Sizzle? I guess not. https://github.com/jquery/jquery#modules https://github.com/jquery/jquery#modules https://github.com/jquery/sizzle https://github.com/jquery/sizzle
  - jessaustin 11y ago
    I was under the impression that jquery bundles the kitchen sink, as well. It's sort of a special case. Those who use it, know what they're getting. The average npm module doesn't emulate jquery.
azov 11y ago
This is a terrible advice - please don't do it. Say, your app depends on libraries foo & bar, and both of them depend on baz. Say, foo is bundled with baz v.1.1 and bar is bundled with baz v.1.2. If you used package manager you'd get baz v.1.2 and everything would work fine because baz 1.2 is API compatible with 1.1. However, it does not mean you can use them interchangeably! If you pass an object created in baz 1.2 to baz 1.1 things might break because internal implementations of the two are different. Even having two instances of the same exact library may not work - e.g. if that library keeps some sort of internal cache. NPM must be fixed so that packages that we depend on can't just be unpublished. Bundling everything together is not the right solution.
- callumlocke 11y ago
  > If you pass an object created in baz 1.2 to baz 1.1 How could that ever happen? Foo and bar are separate deps. How do they pass something between each other? You can't pass something between the two baz versions because they are implementation details inside two different respective modules, foo and bar. The only way I can see is: bar passes you a baz 1.2 object, you pass it to foo, and foo passes that to baz... But if that could cause a bug, the whole setup is just wrong if there's any kind of contract saying that what you're passing is a baz object. If that's the case, baz needs to be a top level dep of your code, and foo and bar might just mention it as a peer dep. And I'm sure the OP wouldn't argue for bundling peer deps. Maybe we need a real example :)
  - yoklov 11y ago
    If I depend on Frobnicator 1.2 and Frobnicator-utils x.y, and that version of the utils depends on and bundles Frobnicator 1.0, then Frobnicator objects created with the utils lib may not be compatable with Frobnicator 1.2. Moreover, if the lib has internal state, then even if its the same version it will be broken
    - callumlocke 11y ago
      That's a broken system regardless of whether anything is bundled or not. If module X has a dependency on module Y, this is an implementation detail of module X and should be completely encapsulated in module X. If for some reason the system needs every copy of module Y to be the same singleton object in memory, then you need to create that instance centrally and pass it around to whoever needs it, not just rely on the Node's require cache mechanism to hopefully return the same copy for two separate require calls in different places. That may be how the require cache works, but that's an implementation detail of Node and not the right way to ensure something is a singleton.

48 points by callumlocke 11y ago

Ok, this finally gave me a use case for webpack as opposed to gulp that I could appreciate, but then it introduced two new potential competitors in Rollup and JSPM, so there's still extra stuff to keep up with. anyway I guess until it becomes industry practice to bundle everything I need to bundle stuff by myself that I will be using just to avoid this situation in the future (until it's fixed, but really I think bundle it all yourself sounds much more secure)

netcraft 11y ago
npm stats jspm 115,692 downloads in the last month rollup 95,038 downloads in the last month webpack 1,407,499 downloads in the last month jspm I believe had a good thing going for a while but webpack has well and truly replaced them now.
- callumlocke 11y ago
  you missed the biggest one: browserify 2,218,006 downloads in the last month But my prediction is Rollup will take off in a big way at some point in the next 2 years. It's not quite stable enough yet, but it's just fundamentally better designed than everything else. Rollup is the only tool I'm aware of that properly exploits static analysis of ES6 module syntax. Every other bundler is full of hacks and moving parts, Rollup's codebase is clean and beautiful. It's already very good for bundling ES6 modular code, it's just still got some kinks when it comes to integrating people's CommonJS code. And I guess not enough people are actually using module syntax yet for Rollup to come into its own, which is a chicken and egg problem. It will get there though. Until Rollup is stable enough, I recommend Browserify. In my opinion Webpack and JSPM both try to do too much and are too prescriptive about workflow. My team switched from Browserify to Webpack a few months ago, and I now find it a bit suffocating and slow.
  - maattdd 11y ago
    Webpack v2 also tries to use the static part of es6 modules (for DCE ?)
    - lollipop25 11y ago
      Yes, Webpack is also trying out "tree shaking" https://github.com/webpack/webpack/tree/master/examples/harmony-unused https://github.com/webpack/webpack/tree/master/examples/harm...

GoBelle 11y ago

best thing I've read all week

wrong_variable 11y ago

Leaving aside all the advertisement and marketing. JSPM -> sounds like a good idea until you try using it, and SystemJS is just sad. Its not the fault of the specs, its just that the creator is having difficulty with funding - as with any other good open source projects. Webpack -> Slow, unstable and documentation is incomplete. RollUp -> I am not going to listen to the author's comment on how awesome his product is -_- I still think browserify is the only bundler out there that is sort of stablish. I locked my browserify@4.0.0 for 3 years and recently moved on to browserify@9.0.0 Being in the JS world you need to be conservative these days - especially if you want to ship in time.

lollipop25 11y ago
No one also cares if you think browserify is awesome. Everyone has their favorites, deal with it.

Ralfp 11y ago

Is Browserify falling out of favor? I've only just recently started to bundle my stuff with it instead of gulp's concat.

callumlocke 11y ago
No, Browserify is still quietly way out in front of everything else (in terms of npm downloads).

pokstad 11y ago

Also, can someone tell iOS libraries to stop relying on Cocoapods? After the github disaster, it should be standard to bundle dependencies.

joewood1972 11y ago

No, de-duplication and conflict resolution is much harder if dependencies are in a bundle. There are many better solutions to this problem: * Fix NPM and make it immutable. If there's a legal problem allow a package to be flagged with a warning and redirected to its new name. * Use bundleDependencies in npm * and maybe even back-up your entire code directory

joeframbach 11y ago

Can someone clarify what would happen in this scenario: - My app requires React. - My app also requires FooBarComponent whose dist is just a giant index.js which includes its own copy of React. - Now I get a bunch of errors because FooBarComponent and MyApp can't share anything between themselves. React really doesn't like it when two copies are running.

exogen 11y ago
FooBarComponent shouldn't have been packaged that way (it can include such a dist file for some people to use, but the npm package shouldn't export that). The typical way is for it to not include React as a `dependency` at all but a `peerDependency`. Then everything will be importing the same instance.
- joeframbach 11y ago
  > (it can include such a dist file for some people to use, but the npm package shouldn't export that) I think that is exactly what the article is suggesting we do.
lollipop25 11y ago
The root of the problem is why FooBarComponent is a giant index.js. Also, why does it have React bundled if it expects to be a reusable component? Also, frameworks like React etc. shouldn't be a bundled dependency. They should be an external dependency or a top-level dependency.

jessaustin 11y ago

Ugh, no. Bundling should be done at the very end, when you're trying to build maintainable software. It's a mistake to bundle in the middle, because then even loosely-dependent modules will be limited to updating only when every intermediate dependency updates. Don't take these decisions out of the hands of the coders who are actually coding software.

lollipop25 11y ago
Are you aware that jQuery bundles Sizzle? I guess not. https://github.com/jquery/jquery#modules https://github.com/jquery/jquery#modules https://github.com/jquery/sizzle https://github.com/jquery/sizzle
- jessaustin 11y ago
  I was under the impression that jquery bundles the kitchen sink, as well. It's sort of a special case. Those who use it, know what they're getting. The average npm module doesn't emulate jquery.

azov 11y ago

This is a terrible advice - please don't do it. Say, your app depends on libraries foo & bar, and both of them depend on baz. Say, foo is bundled with baz v.1.1 and bar is bundled with baz v.1.2. If you used package manager you'd get baz v.1.2 and everything would work fine because baz 1.2 is API compatible with 1.1. However, it does not mean you can use them interchangeably! If you pass an object created in baz 1.2 to baz 1.1 things might break because internal implementations of the two are different. Even having two instances of the same exact library may not work - e.g. if that library keeps some sort of internal cache. NPM must be fixed so that packages that we depend on can't just be unpublished. Bundling everything together is not the right solution.

callumlocke 11y ago
> If you pass an object created in baz 1.2 to baz 1.1 How could that ever happen? Foo and bar are separate deps. How do they pass something between each other? You can't pass something between the two baz versions because they are implementation details inside two different respective modules, foo and bar. The only way I can see is: bar passes you a baz 1.2 object, you pass it to foo, and foo passes that to baz... But if that could cause a bug, the whole setup is just wrong if there's any kind of contract saying that what you're passing is a baz object. If that's the case, baz needs to be a top level dep of your code, and foo and bar might just mention it as a peer dep. And I'm sure the OP wouldn't argue for bundling peer deps. Maybe we need a real example :)
- yoklov 11y ago
  If I depend on Frobnicator 1.2 and Frobnicator-utils x.y, and that version of the utils depends on and bundles Frobnicator 1.0, then Frobnicator objects created with the utils lib may not be compatable with Frobnicator 1.2. Moreover, if the lib has internal state, then even if its the same version it will be broken
  - callumlocke 11y ago
    That's a broken system regardless of whether anything is bundled or not. If module X has a dependency on module Y, this is an implementation detail of module X and should be completely encapsulated in module X. If for some reason the system needs every copy of module Y to be the same singleton object in memory, then you need to create that instance centrally and pass it around to whoever needs it, not just rely on the Node's require cache mechanism to hopefully return the same copy for two separate require calls in different places. That may be how the require cache works, but that's an implementation detail of Node and not the right way to ensure something is a singleton.