kumavis

i want it :heart:

still seeing lots of ci failures on master https://github.com/browserify/browserify/commits/master

@ljharb for back support on bundles, what about reccomending and documenting running babel on the bundle

i dont mean running babel as a transform like `babelify` but running babel once on the output as the last build step. polyfills can be added based on their target....

heres an example. this is a small amount of work for someone who already has the nontrivial task of supporting dead, unsafe platforms EDIT: this config is incomplete. polyfills need...

ok i kinda see how babel as a last step can be infeasible, it can break things like `core-js` I think there should be some test bundles and those should...

> Those deduped modules need to be executed multiple times with different require() path resolution, I think just updating the `moduleId`'s would be sufficient. instead of a redirect module with...

oh I see! I think theres two things that use this pattern: (1) deduplicated modules and (2) browser field redirects. I think its maybe fine that deduplicated modules use this...

so one fundamental issue that makes browserify's internals ugly in a few places is that `stream-splicer` (browserify's pipeline) has no notion of "setting up" vs "ready to flow" so if...

@hawkerboy7 I'm against adding things in browserify that will non gracefully fail in node