
If you write JavaScript tools or libraries, bundle your code before publishing - callumlocke
https://medium.com/@Rich_Harris/how-to-not-break-the-internet-with-this-one-weird-trick-e3e2d57fee28
======
azov
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
> 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
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
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.

------
bryanrasmussen
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
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
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
Webpack v2 also tries to use the static part of es6 modules (for DCE ?)

~~~
lollipop25
Yes, Webpack is also trying out "tree shaking"
[https://github.com/webpack/webpack/tree/master/examples/harm...](https://github.com/webpack/webpack/tree/master/examples/harmony-
unused)

------
wrong_variable
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
No one also cares if you think browserify is awesome. Everyone has their
favorites, deal with it.

------
jessaustin
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
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
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.

------
joeframbach
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
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
> (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.

------
joewood1972
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

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

~~~
callumlocke
No, Browserify is still quietly _way_ out in front of everything else (in
terms of npm downloads).

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

------
GoBelle
best thing I've read all week

