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
ES Modules + .mjs #37
Comments
So we use this lib in Node and the browser currently. We ship two builds. A the default build and an immutable build. The quick experiment moved to esmodules syntax and then builds using babel-plugin-add-module-exports. Its not quite completely working yet because I missed some of the However that aside we do have a prelimary finding: builds are 5kb larger. π So, the challenge is can we retain the esmodules and get that number smaller. I'm sure some combo of plugins and transforms could eventually do this. And then downstream users can consume the esmodules src directly though I'm not sure what the benefit of that is yet. Tree shaking won't mean much given this thing basically just exports a constructor function for consumption. (Open to learning I'm wrong about all of this too of course.) |
hi Sean! yeah, i agree if it's useful to module-people, we should do it, then browserify-them-away for the |
It occurs to me that if the esmodules src gets published with the prebundled CJS src itβll mean the on disk size of the package in node_modules will be way over 200KB. Even just the esmodules src is around 130KB. So best case 50KB larger on disk. Also note this is the equivalent of shipping coffescript source to npm. In the past regarded as an inappropriate way of doing things because it forces downstream consumers to have a build step defined by upstream packages. Maybe this is better now that thereβs some agreement on the syntax of esmodules but does mean rewriting to match the Still open to cracking this nut but I want to remain clinical about our chosen trade offs and why. |
Update: got it mostly working in the Was pleasantly surprised to see The on disk node_modules payload is still quite a bit bigger but it'll be interesting to play with this using unpkg and a browser. |
Update!1!! I got it totally working. Tests and lint are passing. I also figured out a sorta-hacky way to support esmodules alongside the cjs source. The tradeoff is a breaking change to the interface. Instead of the library exporting And the best news! Entire on disk node_modules payload is smaller at 76KB!! The build uses Webpack for creating a UMD bundle of spacetime that I also had to use |
wow! nice work brian. i just checked it out and things look great. .... just thinking aloud - nice work! |
Yeah I think so but we'll want to make the CJS build a bit conservative to support, at least, Node 6.10 --- think this last commit fixes that by adding a rollup/babel plugin. Bumps cjs source filesize up to 42KB tho! Def interested to see if we can get that |
punting this refactor for now, as it's a good idea, but it required a breaking top-level api change, for the immutable/mutable stuff, and increased the filesize a bit. |
Yes, I agree. It is a bit disappointing but this was a nice experiment and, objectively, esmodules cost/benefit isn't there yet. |
Wow how did I miss this thread until today. (Sorry been migrating GitHub emails). Let me catch up here. So did i see that modules are a branch? Also, you had found builds are smaller still? Maybe a tl;dr will catch me up. |
tl;dr we managed to get the payload of it smaller IF we pre-bundled the esm/cjs source but that gains us little a breaking API change for a marginal payload win and a much more involved set of deps and build gymnastics to support it. kinda not worth imo but we'll keep this PR open and play with it time to time to see if the space matures. |
I added #71 as I think one the main benefits of switching to ESM could be to have the timezone data tree-shaked, which could reduce the final size of the code rather drastically I think |
been thinking more about this, open to any recommendations. the advice usually is to use es-modules internally, then babel-them-away for the 'main' build. but i've seen webpack complaining about main pointing to a built file... so to avoid breaking any node projects, my gut says but I saw this and thought it was a nice solution: is there a good way to spin our build into a This stuff still hurts the brain, but module support is like 80% in caniuse now! People are doing some neat stuff and we should support it. |
hey, i got a i could be convinced otherwise, but I think it's probably still too early to merge this. I think I got to the same point as brian did a year ago. Lovely idea, still too weird. |
hey there - ... I guess that's it? |
Hi there!! This is really neat! I was wondering if any of us at webpack could help ship this code over using ES Module Syntax?
Can include motivations if needed! π¨βπ¬π₯
The text was updated successfully, but these errors were encountered: