Is there a way to tree-shake unused imports?

[anzorb]

Good morning,

Thank you for this wonderful library.

I am a bit confused about this tree-shaking use-case:

// file: utils.ts
import { Box3 } from 'three';

export function A() {
   return new Box3();
}

export function B() {
   return 'I don't need three.js!';
}

// file: index.node.ts

export {
B 
} from './utils.ts';

I expect that neither A nor three.js to be bundled, but the latter is getting bundled in. Is tree shaking suppose to remove unused imports along with unused methods/constants?

Thanks in advance!

[lxsmnsyc]

if the module has side-effects (specifically, 'three') and was imported, it would still be bundled.

[hyrious]

In fact, three can only be removed if its package.json has sideEffects: false and you are bundling it instead of making it external.

Is there any way to externalize AND mark a library as no side effects? It looks like we must install a library locally to tell esbuild to remove it from the output.

[Bessonov]

I think I have the same use case. Basically, I wish to have a shared module in a monorepo that can be used from frontend and backend. (But in reality the setup is more advanced that utils-frontend and utils-backend modules can satisfy). The problem arises if some node-native modules like fs are imported, even they aren't used in the chain of calls. This setup works fine with webpack if fallback option is specified.

It would be a game changer for me if I could use similar option with snowpack, or like in this request - it would magically omitted.

In fact, three can only be removed if its package.json has sideEffects: false and you are bundling it instead of making it external.

I think this is not precise enough. sideEffects is a signal for consumer about possible side effects in regards of using/importing the module in question. AFAIK it doesn't have any impact within the module. In this concrete example I have the same expectations like @anzorb . But I'm not sure if this expectation stands on publishing.

[evanw]

The way to do this is to mark the relevant package as side-effect free using sideEffects: false, as described above. Node built-in modules such as fs have also been marked as side-effect free since version 0.14.7 of esbuild. Other than in these two cases, JavaScript imports are supposed to have side effects (since imports are not lazily evaluated in JavaScript) so esbuild will not remove them.