bundlejs: Treeshaking doesn't always work
@chakra-ui/react shows the same size whether you export a few components or all of them. If you esbuild it locally however, the generated bundle is much smaller.
bundlejs: Bundle size is 920.21KB -> 297.6KB (gzip)
vs
esbuild: out.js is 397229 bytes
The package in question has both CommonJS and ESM exports. main field in package.json points at the CommonJS one. Could that be the issue?
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 27 (18 by maintainers)
That makes sense. It just seems there’s a cache for JS files, so I thought there would only be 2 requests to each of them.
@cutiful Awesome, though it’s still a WIP, ideally
esbuild-wasmtreeshaking would work just work properly without needing to run twice, I’ve already created an issue on https://github.com/evanw/esbuild/issues/3129.The 2 network requests are nesecary to determine which extenstion to use when fetching the file, because depending on the package the import could be
./index.js,./index.mjs,.mjs,.js,.ts,.mts, etc… in order to determine the right extension I send HEAD requests which are small and faster than GET requests, if the request passes then that’s the right package if it doesn’t then it is not@cutiful It seems you’re right, the issues seems to CJS. I’ll take a closer look at this and get back to you