generateBundle ChunkInfo modules does not contain treeshaken modules

[BPScott]

• Rollup Version: 2.18.1
• Operating System (or Browser): mac
• Node Version (if applicable): 12
• Link to reproduction:
  • Super minimal: https://repl.it/@BPScott/rollup-repro-bundle-modules#src/main.js (expected behavior - empty.js is present in the console.logged arrays in both rollup versions)
  • More complex, but shows my use-case for needing this behaviour https://github.com/BPScott/rollup-bundle-modules-test

Expected Behavior

In the generateBundle hook you can do the following to get an array of all the modules used within all the bundles.

 generateBundle(_generateOptions, bundle) {
    const bundleModuleIds = Object.values(bundle).flatMap((fileInfo) =>
        Object.keys(fileInfo.modules)
    );
 }

In rollup v1 all modules ids are present in that array. I would expect the same for rollup v2

Actual Behavior

In rollup v2 modules that have been tree shaken away are not present in the above bundleModuleIds array

[lukastaegert]

Yes, this is not a bug but is listed as a breaking change of version 2, see https://github.com/rollup/rollup/releases/tag/v2.0.0:

Modules that are completely tree-shaken will no longer be listed as part of any chunks in generateBundle

The reason is technical but the thing is, a tree-shaken module IS not part of any chunk, so it does not make sense to list it as part of any chunk. Unfortunately, the new chunking algorithm WILL not list it as part of any chunk, so this cannot easily be fixed. The best idea to mitigate certain use cases I had so far would be to allow for plugins to specify that a module should never be tree-shaken. Then this module would again end up in some chunk even if it is empty. This is not done yet, but out of curiosity, would this solve your use-case?

[BPScott]

Thanks for that context and the link @lukastaegert, I missed that part of the changelog :) Not including fully tree-shaken modules in the chunk by default makes sense.

I think a mechanism to mark particular modules as never treeshakable would solve my use case. I tried changing the contents that the css files export to trigger a side effect, and thus stop treeshaking and my output included the previously removed content:

const properties = JSON.stringify(postCssOutput.tokens, null, 2);
- return `export default ${properties};`;
+ return `console.log('');export default ${properties};`;

In my original poking at this is issue while not fully groking the documentation I tried using returning an object from my transform hook that set moduleSideEffects: true thinking that might mean "assume this module always has a side-effect, don't bother checking the side-effect finding algorithm" (as an inverse of false meaning "assume this never has a side effect, don't bother checkking the side-effect finding algorithm") but upon closer reading of the docs true just means "defer to rollup's side-effect finding algorithm. It sounds like I was grasping for a similar idea to your not-yet-implemented opt-out option.

[tivac]

You can use this.getModuleInfo(id) to get info about the dependency graph, including modules that were tree-shaken away. It's what I'm using for @modular-css/rollup and has been working well to enable investigating the entire graph including tree-shaken CSS modules.

https://github.com/tivac/modular-css/blob/195da8f0975058c4e0a050267862e11b77e6c2e3/packages/rollup/rollup.js#L214

[lukastaegert]

There will be a feature to address this in the next minor version: #3663