Tree-shaking Improvements

[bigtimebuddy]

@Zyie had a proposal awhile ago, that I'm reconsidering for v7.

Rollup has an option preserveModules which would maintain individual files upon export. There are a few benefits to this approach instead of bundling into a single file. It's faster to build but more importantly helps end-user with tree-shaking (removing unused code).

With the exception of the browser builds (pixi.js and pixi.js-legacy and @pixi/webworker), all code would be exported without minifying. Types generation would also be faster/easier to export as individual files.

Every file in the source would likely get an export that looks something like this:

• [package]/dist/index.js
• [package]/dist/index.js.map
• [package]/dist/index.mjs
• [package]/dist/index.mjs.map
• [package]/dist/index.d.ts

[choephix]

@bigtimebuddy Hey, I wasn't sure where to ask this, so I'm posting it here:
What's the current proper way to add PixiJs v7 as a dependency to a fresh project?
Is https://pixijs.io/customize/ still the best way to go (as I've done in the past with v5 and as was recommended here) or should we simply do npm install pixi.js and assume that modern bundlers like Vite (which I'm using) and Webpack will tree-shake it just fine and the resulting js size will be the same?

[bigtimebuddy]

I would do this in two steps:

1. For a new browser project, just use pixi.js, it's the easiest out-of-the-box solution
2. When and if you need to optimize for filesize, consider using individual packages

If you create a custom build with individual packages, it will save you maybe 100-150KB (best case) over a foot print of less than 470KB. So not huge, but something.

Because Pixi statically installs extensions, Webpack and other tree-shaking bundlers have a hard time shaking anything of significant value.

Keep in mind, this is really only for filesize. Performance is not going to be affected by reducing packages.

Hope that helps.

[choephix]

Awesome, thanks!