Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
browserify interoperablity #552
one of the issues I've had with rollup is I can't use all the previous modules I've written with it due to interoperability issues, so after talking to @nolanlawson about it I decided to write some stuff to make browserify modules 'just work'.
also you'll want to use some specific versions of rollup modules due to the pulls stalling specifically
@calvinmetcalf Um, how can I actually install those forked modules? I don't know if this is something different for NPM 3 or what. I do remember it was possible just like
Woops yeah the rollup pre publish build thing doesn't work with installing
On Wed, Jun 1, 2016, 4:05 PM Daniel K. email@example.com wrote:
You can clone it, build it and manually link it if you want it right now
On Wed, Jun 1, 2016, 6:03 PM Calvin Metcalf firstname.lastname@example.org
Since Nolan keeps on linking to this I thought I'd give an update/overview
Can you use arbitrary node modules and they "just work" like in browserify?
No, there are valid browserifable structures that do not work with rollup so it doesn't just work all the time.
But if you are using commonjs modules with rollup you are likely missing out on rollups benefits as they will never be tree shaken out ever (as the current commonjs plugin is set up) and they have a function called on at runtime (like Webpack or browserify) which imposes a startup cost that traditionally rollup omits.
Is this fixable?
Yes but probably not by me alone. The mandatory and blocking one is circular dependencies. Basically rollup assumes es6 module rules where depended on modules are always evaluated before the script that imports them is. Commonjs evaluate modules at the exact moment it's required the first time.
It would seem to me the straight forward method would be for rollup to simply inline the module being required at the place it was required (instead of before it) but rollup has no ability to do that at the moment. If I both have time and can figure out how I'll open a pull, I don't know how likely that is to happen though (both the time and me being able to figure it out) but even if I did I'd probably need to discuss with the rollup folks about how to do it.
But then we're great right?
As I said before commonjs modules don't tree shake out right now, this is because of how they are defined right now which rollup sees as a side effect so never removes it, I have a fix to the commonjs plugin but it doesn't currently handle top level returns, so I need to fix that.
But then right?
So there is one issue I have with rollup that makes me hesitant to use it as a browserify replacement and that is its strict inclusion of all code that produces side effects or might always. This means if a imports b which imports c which imports d which imports e which imports f, g, h, and i then if e has side effects but the part of b that imports c is tree shaken out and thus c and d are removed, e and thus f, g, h, and i will still be included. This basically breaks tree shaking in practice but fixing it is a spec divergence so we'll see if my pull to fix it gets merged or if others have better ideas.
So rollup is pretty much broken and I shouldn't use it?
Most definitely not, it is a great tool written by great people and it is totally works for certain work flows such how pouchdb is using it to bundle it's self, it's just not a browserify replacement... Yet.
(sent from my phone so apologies for any autocratic typos)