-
Notifications
You must be signed in to change notification settings - Fork 76
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
Esnext esm/* target, rather than es5? #65
Comments
This brings up a good point - how important is bundle size for crank? IMO we should strive to keep it as low as possible. Preact has a relentless approach to this. You see PRs made that shave off a few bytes and the team celebrates. I love that and it’d be cool to adopt a similar mindset with this project. |
@nykula So my questions:
@ryhinchey |
@brainkim People who setup Rollup, Webpack etc manually enable transforms for individual packages with a negative regex lookahead: So assumption 1 I'd change to, everyone who uses the esm versions might not have async/generators in their environment by default, but they do have an option to enable them, which they should be reminded of in documentation. Regarding copyright headers. Babel inserts them for transpiled async and generators too, those of facebook/regenerator, so switching to it won't provide question 2 suggested gains. However, tslib developers are planning to relicense as 0BSD public domain equivalent, which is also my personal preference for own code. So the header requirement will disappear, though not very soon I guess. microsoft/tslib#47 (comment) |
If people are saying that it’s okay to ship ESNext for ESModules, that’s what we’ll do. Although the whole |
Just as an FYI, tslib is now relicensed! |
Thanks for chiming in here @DanielRosenwasser ! |
Crank is now shipped untranspiled and dependency free in 0.2.0. And according to bundlephobia it is 4.4 KB minified and gzipped (https://bundlephobia.com/result?p=@bikeshaving/crank@0.2.0). Would be nice to get some automated bundle size notifications in PRs and do all the fancy tricks Preact does to get an even smaller bundle size, but I’m okay with this for now. |
Package of
@bikeshaving/crank
0.1.1 at npm has a 142k esm/ dir. Odd because github files are much smaller, 42k only (10k gzip) for all direct src/ children. From what I see in esm/index-4b79835a.js, the build system adds huge polyfills for very old browser engines, and replaces all usage of generators and async with es5 state machines. Since these files are es modules whichexport
stuff, one can't justrequire
them in old node or run in browser asscript
without an additional transpilation step on behalf of the app developer. My question is, how does applying such radical transforms to the esm dir help users of old engines in practice then? Doesn't it negate the top benefit of crank, excellent runtime performance in modern browsers due to using their native features? Would reconfiguring the build system to keep esnext generators and async in the esm dir make sense?The text was updated successfully, but these errors were encountered: