-
-
Notifications
You must be signed in to change notification settings - Fork 447
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
stdlib-js/esm package update #1059
Comments
👋 Hi there! 👋 And thank you for opening your first issue! We will get back to you shortly. 🏃 💨 |
Hey, @walterra! Thanks for reaching out! To help us recommend the best approach, how much of |
Hey, thanks for getting back so quickly! For now we are looking into using I noticed that each individual package has an We're evaluating if we're able to pick up the library to be used in parts of Kibana (https://github.com/elastic/kibana). |
Thanks for the info! Let me discuss internally with the team and circle back! |
@walterra To help provide us with a bit more context, how are you currently handling CommonJS packages in your production workflow? Are you wanting esm variants because that's what your tooling caters to, or are there specific issues you encountered with CommonJS |
We can handle CommonJS packages and got it working with We then had a go at your custom bundler which resulted in a 1.3MB package for those 2 libraries. Visualized here with Next we tried with a webpack setup which was able to bring that down to ~173KB. I think the following is just for the Then we found your esm repo and using rollup with the esm version allowed us to bring down the We saw that you seem to make use of If you'd be able to pull off releasing individual minified/optimized packages like this on npm that would certainly hit a sweet spot! But I'm not sure it's necessary. If the current esm repo was updated and published to npm we could use that and do deep imports from within our code with the same effect. If I'm not mistaken that's also lodash's approach: Individual npm packages for CommonJS and a single esm package. Not sure if hybrid package releases are an option at this stage, I'm a bit out of the loop regarding the current ecosystem 😅 . Let me know if you need more information or if we can be of any help. |
Thanks for the detailed write-up! |
@walterra Did you try just using the |
Ah, okay. I see from the source map explorer images that you don't seem to be loading the |
I did some more testing with bundling. The initial bundle increases (1MB+) were part of a quite large PR that included a lot of other code additions. I created some dummy draft PRs that just add
|
@walterra Yes, the code has been refactored, particularly among dependencies, such as Just as a heads up, we are working on this. A few comments:
To reproduce the build, you can do the following:
This should generate something like the following: Note, as you may already be aware, there are some nuances when attempting to bundle an already bundled file, but at a minimum you can verify that the above bundle works in Node.js by adding the following script to the import chi2test from './bundle.min.js';
var x = [
[ 20, 30 ],
[ 30, 20 ]
];
var out = chi2test( x );
console.log( out.print() ); and running via the command-line. |
In short, I think there is a path forward here which doesn't require updating the "tree-shaking" is not really necessary when using individual What does matter is how bundling is done. In particular, making sure license headers are minified, etc. Hopefully, the above sequence demonstrates that. Longer term, we do need to provide an ES Module offering in order to accommodate bundlers such as rollup which have poor support for CommonJS. We've thus far avoided moving in this direction, as dual packages are still a headache to maintain in Node.js-land, we maintain strong backward compatibility guarantees, and custom loaders are still experimental. |
Thanks for being on top of this so quickly, this looks promising! Completely agree that the bundle size isn't really related to whether it's CommonJS or esm, it was just what's brought us further in our experiments quicker without knowing too much about stdlib's whole setup. Looking forward to see further improvements, thanks! |
Quick update: did some refactoring over the weekend, and we were able to reduce the bundle size a bit further (~102KB). As a consequence of refactoring, there should also be a noticeable performance boost. Below is an updated source map based on a bundle generated using the sequence documented above. |
@walterra We have released a new patch release ( |
Thank you so much for the update, we'll try to pick this up! |
@walterra Let us know if there are other stdlib packages (and/or feature requests) that we can help prioritize for your use case. |
Thanks for the ping! So here's where we're at now with the different packages we evaluated on our builds:
Version Here's our I know too little about We're a bit caught up with other stuff for the moment, but will continue to experiment with |
Are there any plans to update the
stdlib-js/esm
repo/package? The repo (https://github.com/stdlib-js/esm) and npm package (https://www.npmjs.com/package/@stdlib/esm) are atv0.0.3
and use some older code inndarray
relying oneval()
which blocks us from using it.We're evaluating using
stdlibjs
and it looks really promising. Unfortunately the standard package sizes are quite large for client side code. Some experiments with theesm
variant androllup
showed there's quite some potential to bring the bundle sizes down using that approach. Ifstdlib-js/esm
was up to date and published tonpm
we could make direct use of it without the need of a fork and/or custom bundling.Is that something we could help out/contribute potentially?
The text was updated successfully, but these errors were encountered: