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

Browser support #29

Open
brettz9 opened this issue Mar 3, 2020 · 4 comments
Open

Browser support #29

brettz9 opened this issue Mar 3, 2020 · 4 comments

Comments

@brettz9
Copy link
Contributor

brettz9 commented Mar 3, 2020

Your dependencies all appear that they would work in the browser, at least when pulled in through Rollup + rollup-plugin-node-builtins. Would you be willing to have source converted to ESM (producing also a UMD build)?

@jhermsmeier
Copy link
Owner

Producing a UMD build can easily be done with browserify – which is something we could add, so I don't really see the need to convert to ESM here (yet) – unless you have some convincing arguments?

@brettz9
Copy link
Contributor Author

brettz9 commented Mar 3, 2020

Besides the ESM support already available in Node 12 through the --experimental-modules flag, IIRC, browserify, unlike Rollup, doesn't support making an ESM distribution, so one couldn't have an ESM build that could be imported in the browser). (I can't Google now to find the issue, as behind firewall in China with no working VPN.)

I like to use ESM in browser demos as it allows working against source without a build step. But this is not a pressing need for me at the moment. I just figured if making the steps to ensure the bundles worked in the browser, that one might as well future-proof the code and provide that functionality along the way.

@jhermsmeier
Copy link
Owner

IIRC, browserify, unlike Rollup, doesn't support making an ESM distribution, so one couldn't have an ESM build that could be imported in the browser).

Right – that's not supported yet. Would having dedicated browserify bundle with a global export help with that (i.e. browser/envelope.min.js which exposes Envelope)? I'm not familiar with rollup, but I'll test some things later and let you know what the conclusions are.

@brettz9
Copy link
Contributor Author

brettz9 commented Mar 3, 2020

A global export would be helpful, sure, whether in a browser-specific build (wrapping the code in an IIFE to avoid conflicts and just setting the global window, this, or self), or UMD (i.e., combining global setting with Node/CJS and AMD support). (Rollup exposes these with its output.format as "iife" or "umd", or also allowing "cjs" for Node only and "esm" for the proposed ESM distribution.)

So while a regular global would satisfy the major concern of this issue, I happen to prefer ESM for avoiding any globals or keeping track of dependencies out of context within my HTML.

Rollup is very well documented and easy to setup and use (compared to Webpack or even Browserify), with the small caveat that you generally need to use plugins when importing npm dependencies (@rollup/plugin-node-resolve, and if the deps. don't themselves have an ESM export, e.g., as indicated in module of package.json, then also @rollup/plugin-commonjs and if you need native Node module polyfills for the browser, possibly rollup-plugin-node-builtins) or if replacing require of JSON (i.e., @rollup/plugin-json); and to minify one needs rollup-plugin-terser or such (and if babelifying, rollup-plugin-babel--all of which I have found work well).

Rollup also has the advantage of working with parcel, a popular means of making it easy to smoothly facilitate the installation of modules without users needing to manually manage this config.

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

2 participants