This is a terrible advice - please don't do it.<p>Say, your app depends on libraries <i>foo</i> & <i>bar</i>, and both of them depend on <i>baz</i>. Say, <i>foo</i> is bundled with <i>baz v.1.1</i> and <i>bar</i> is bundled with <i>baz v.1.2</i>. If you used package manager you'd get <i>baz v.1.2</i> and everything would work fine because <i>baz 1.2</i> is API compatible with 1.1.<p>However, it does not mean you can use them interchangeably! If you pass an object created in <i>baz 1.2</i> to <i>baz 1.1</i> 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.<p>NPM must be fixed so that packages that we depend on can't just be unpublished. Bundling everything together is not the right solution.
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.<p>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)
Leaving aside all the advertisement and marketing.<p>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.<p>Webpack -> Slow, unstable and documentation is incomplete.<p>RollUp -> I am not going to listen to the author's comment on how awesome his product is -_-<p>I still think browserify is the only bundler out there that is sort of stablish.<p>I locked my browserify@4.0.0 for 3 years and recently moved on to browserify@9.0.0<p>Being in the JS world you need to be conservative these days - especially if you want to ship in time.
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.
Can someone clarify what would happen in this scenario:<p>- My app requires React.<p>- My app also requires FooBarComponent whose dist is just a giant index.js which includes its own copy of React.<p>- 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.
No, de-duplication and conflict resolution is much harder if dependencies are in a bundle. There are many better solutions to this problem:<p>* 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.<p>* Use bundleDependencies in npm<p>* and maybe even back-up your entire code directory