Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider not self-hosting modules #43

Open
mattdesl opened this issue Jul 11, 2018 · 5 comments
Open

Consider not self-hosting modules #43

mattdesl opened this issue Jul 11, 2018 · 5 comments

Comments

@mattdesl
Copy link

It seems this plugin is the go-to way of supporting Node.js builtins in rollup (like util), however it is really outdated and will always lag behind browserify builtins since it self-hosts all the modules.

It would be better if there was some way to install & depend on all modules, like util, and transpile them to ES6 as a pre-publish step. This module would still need to be built & updated manually every time any of the dependencies change, but something like greenkeeper could potentially help here.

Example: browserify's util has been continually updated over the last few months to keep parity with latest Node.js changes (promisify etc), whereas this module (and thus rollup devs) are stuck on a version from 2016.

@calvinmetcalf
Copy link
Owner

if you have any ideas on how to transpile them to ES6 I'm open to suggestions

@mattdesl
Copy link
Author

Hmm was it all done manually?

I’ll think about it! Something I’m toying with is the idea of a new plugin that somehow merges rollup + browserify (a little differently than rollupify). The end result may be a little less optimized / tree shakeable than pure es6, but it has some other benefits like more robust handling of node code, builtins, and will not lag behind Node.js core updates as quickly. The two plugins could co exist to give users the choice between bundle size & robustness.

@calvinmetcalf
Copy link
Owner

yes, these were all artisanal hand ported by me originally and while some of them could probably be very easily changed, others are going to be a lot more difficult due to:

  • weird export strategies (e.g. module.exports is an object that also has things defined off it)
  • weird circular dependencies (**cough** streams, which is also my fault on that end)
  • and just lots of dependencies (crypto)

@calvinmetcalf
Copy link
Owner

one tricky thing is that util is one that gains a lot from being able to tree shake it out because it has a bunch of random things in it, which is also one that updates very frequently

@bionicles
Copy link

babel?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants