Skip to content
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

Tree-shaking broken. Erroneous [ignored-bare-import] warning. import type statements possible culprit. #2334

Closed
mikestopcontinues opened this issue Jun 20, 2022 · 4 comments

Comments

@mikestopcontinues
Copy link

I'm using esbuild in a monorepo to bundle a library, then rebundle it in a second package (specifically, a serverless func). However, I'm getting a series of errors that completely breaks tree-shaking, resulting in a 5MB bundle instead of about 300kb.

The problem seems to be that during the initial bundling process, many of the imports are tree-shaken, but the bare import statements remain:

import './chunk-TFQ3YM4A.mjs';
import './chunk-7TSMCAJT.mjs';
import './chunk-7W62PHEE.mjs';

Those files shouldn't be included at all. The package is marked "sideEffects": false. For reference, I'm not directly importing these files into this entry point. They're within an import type {} statement. The types get dropped, but the web of imports remain. (This seems to be a known issue. #1794 #1435).

Some of the apps in this monorepo still use webpack, which shakes away those useless imports just fine. The problem arises when using esbuild to bundle a package that depends on the library with the bunk imports.

When I do that, I get this warning, 44 times:

▲ [WARNING] Ignoring this import because "libs/arc-model/dist/chunk-TFQ3YM4A.mjs" was marked as having no side effects [ignored-bare-import]

    libs/arc-model/dist/index.mjs:1:2430:
      1 │ ...rt{a as wo}from"./chunk-IOOPTIQW.mjs";import"./chunk-TFQ3YM4A.mjs";import"./chunk-7TSMCAJT.mjs";import"./chun...
        ╵                                                ~~~~~~~~~~~~~~~~~~~~~~

  "sideEffects" is false in the enclosing "package.json" file

    libs/arc-model/package.json:4:2:
      4 │   "sideEffects": false,
        ╵   ~~~~~~~~~~~~~

Is there workaround for handling this issue? For this particular use-case, the size difference has a big impact on performance.

Thanks.

@evanw
Copy link
Owner

evanw commented Jun 20, 2022

I have read your post several times but I can't figure out what your problem is exactly. Can you provide a code example that demonstrates the problem?

If "sideEffects": false is authored incorrectly and the incorrect annotation can't be changed, you can disable annotations to pretend the "sideEffects": false isn't there. Or if the warning is correct but you would like to not see the warning, you can disable it with --log-override:ignored-bare-import=silent.

@mikestopcontinues
Copy link
Author

It's a two-sided problem.

Part of the problem is that I'm importing a library that has rogue import statements into an esbuild bundle. These import statements don't do anything, so they should be tree shaken away. Instead, esbuild gives me a warning and doesn't tree-shake them, resulting in a bloated build. The library itself is rightfully marked "sideEffects": false.

The other part of the problem is that the library includes these rogue import statements. I'm using tsup to bundle them, and they include the aforementioned esbuild issues in their documentation. That said, it may be how they're using esbuild, or possibility how they use rollup, that's causing the issue. In any case, if I do a pure esbuild bundle, I don't get the warning messages when included in my app, but the app bundle ends up even bigger.

I'm not doing anything strange in the repo either. There's a large, obvious tree of pure config that can be shaken that simply isn't getting removed.

Anyway, I've been able to reproduce the problem in a stripped down version of my monorepo, but it's still fairly large, so I'll try to whittle it down some more tomorrow before posting it.

@evanw
Copy link
Owner

evanw commented Jun 24, 2022

Marking as unactionable until a demonstration of the issue is provided.

@mikestopcontinues
Copy link
Author

Closing the issue for now. I was able to prevent the library bundle from sprouting those bare imports. Tree shaking in the app is still not working, but it may be due to args passed in by the AWS CDK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants