Tree shaking on a meteor package

Hello !

I’m working on a app split into several package, and one of them exports some React components.
Let call it component:provider for simplicity sake

In component:provider/client/main.js, i’ve got something like that :

export { default as Foo } from "../imports/ui/components/Foo.jsx";
export { default as Bar } from "../imports/ui/components/Bar.jsx";

// ....

Let’s say i’m consuming Bar in my app, and only Bar :

import Bar from "meteor/component:provider";

// ...

Ok, so when i npm run visualize, and check bundle, i can see that Foo is onboarded

Are my expectations unrealistics, or should a dead code elimination normally clean these bits ?

I guess tree shaking is hard, and cannot infer all situations, so maybe i could find a workaround.
I’ve found that i can directly import my component from app, if my consumer knows its path :

import Bar from "meteor/component:provider/lib/ui/component/Bar";

It looks a bit dirty to me, but why not ?
The thing is that i would like my package to be built, depending on an ENV specifying a theme:

Package.onUse(function (api) {
  const style = process.env.STYLE;
  const getMainFile = (arch) =>
    `lib/${arch}/main${style ? `.${style}` : ''}.ts`;


  api.mainModule(getMainFile('server'), 'server');
  api.mainModule(getMainFile('client'), 'client', {
    lazy: true,

So ideally, I don’t want my consumer to import a specific file, when he doesn’t have to know which theme i’ll be using.

What would you advise in this situation, how do you organise your imports and exports in Meteor to optimize build output ?

Thanks for your help !

Hello !

So there’s a PR that doesn’t seem stale about optimising tree shaking : Tree shaking by renanccastro · Pull Request #11164 · meteor/meteor · GitHub

As a workaround, before seeing these features in a new version, i’ve created a babel plugin that overwrites imports, based on theme defined in env variable. With this, I don’t have any unused file exported from my package.

Have a nice day !