Make this package tree-shakeable
See original GitHub issueI’m building a UI library which exports a bunch of stuff, only some of my components rely on this package so it would be desirable that if a consumer of my package doesn’t use component relying on tabbable
it would be tree shaken out of the final bundle. However it’s not the case right now.
Let’s focus on 2 common tree-shaking deopts:
- no ESM bundle (this package) exports only CJS format
- top-level static properties, as in
module.exports = tabbable; tabbable.isTabbable = isTabbable;
Action items:
- migrate source to ESM + build CJS format from it, point to CJS from package.json#main and to ESM from package.json#module so bundlers can pick appropriate file
- change exports shape to
export default tabbable; export { isTabbable, isFocusable };
Intent to implement - yes (was already implemented in https://github.com/davidtheclark/tabbable/pull/38 )
Issue Analytics
- State:
- Created 5 years ago
- Comments:6 (5 by maintainers)
Top Results From Across the Web
How To Make Tree Shakeable Libraries - Theodo blog
Check whether the library is tree shakeable by testing it against a known application in a controlled environment · Use ES6 modules so...
Read more >How to build tree-shakeable JavaScript libraries - Cube Blog
What is tree-shakable code? In the example above, two functions were exported from the module and only the “used” one made it to...
Read more >Tree Shaking - webpack
Tree shaking is a term commonly used in the JavaScript context for dead-code elimination. It relies on the static structure of ES2015 module...
Read more >How to make your library tree-shakable - Level Up Coding
Basically, Tree shaking is detecting which exports are unused in our application when bundling and won't include it into our bundler. Achieve Tree-shaking....
Read more >How to write a tree-shakable component library
lets us work in a monorepo where our ui library is one package and our ... ES Modules make it possible for bundlers...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
It won’t if you are going to provide same exports shape for both ESM & CJS files - the compatibility only breaks when people try to use so called auto exports for CJS, so basically transforming
export default foo
tomodule.exports = foo
. Transform to compliant safe version -module.exports.default = foo
is completely safe.Unfortunately bundlers, minifiers & such are quite conservative regarding this stuff. Most of the bundlers simply bail out on CJS files because of its dynamic nature (even though most of the real world files have static exports). In order to perform safe tree shaking a tool has to analyze the program and if it’s unsure if a statement has no side effects then it’s marked as unsafe to be removed.
I’ve illustrated this problem some time ago with a simple repro case. Consider a simple structure:
classnames
(example of CJS-only library)classnames
is still in the bundle, although it is not used by the “app”.I see, thanks for pointing that out. Doesn’t hurt, but seems ineffective. Thanks for #70