-
-
Notifications
You must be signed in to change notification settings - Fork 791
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
Use classes to improve tree-shaking #268
Comments
This package was done to be compatible with ancient browsers, probably not actual now. But you can import pre-build files from dist https://github.com/nodeca/pako/tree/master/dist. Will it solve your problem right now, without changes? |
Not really because I'm creating an ESM-first web component so I cannot If we don't want to update the code, an alternative solution would be to produce ESM files for pako_deflate.js and pako_inflate.js but it feels counter productive since ESM was designed to produce compact bundle with a static structure. In other words, |
Since we are already using Babel, I believe that |
@puzrin I too only need to use |
@ggrossetie @rlidwka is this a change that you would be interested in supporting? This library has like 10m+ users tree shaking would be a really good add especially since that is far more modern. @ggrossetie @puzrin what changes would be needed to add that support is it really just a simple as adding |
Yes. |
From my understanding, classes don't tree-shake as well as ESM Modules, even static. That's because you can always reference a method by name: class MyClass {
myMethod() { }
myMethodINeverUse() {}
}
const instance = new MyClass();
instance.myMethod();
let methodName = 'myMethodINeverUse'
instance[methodName](); ESM Modules don't really exhibit this issue and are better for tree-shaking: export function myMethod() {}
export function myMethodINeverUse() {}; Babel, Webpack, and Rollup will all tree-shake when you do:
And even if you were to import You can even do import * as pako from 'pako';
const pakoFn = 'import';
pako[pakoFn]() That's a side-effect where you don't actually support clean tree-shaking of imports. See: https://webpack.js.org/guides/tree-shaking/ TL;DR: Drop |
Also, I'm pretty sure you can do import { deflate } from 'pako/lib/deflate.js';
import { inflate } from 'pako/lib/inflate.js'; And you're basically tree-shaking yourself. Though because the files are using |
See nodeca/pako#268, there is some issue with pako tree shaking ootb.
See nodeca/pako#268, there is some issue with pako tree shaking ootb.
See nodeca/pako#268, there is some issue with pako tree shaking ootb. We don't need all the inflation stuff in our bundle.
I've noticed that, currently, it makes little to no difference to use
import {deflate} from 'pako'
rather thanimport pako from 'pako'
.import pako from 'pako'
import {deflate} from 'pako'
While investigating, I saw that Inflate was not removed from the bundle but if I convert
function Inflate(options)
to a classclass Inflate
then it's working as expected:Is there a particular reason for not using classes? Will you consider a pull request with that change?
The text was updated successfully, but these errors were encountered: