Expose module and bundle exports from hooks

[gerardmarquinarubio]

Feature Use Case

Easier to write plugins that access a module's exports, for example:

// myTest.ts
function do() {
  ...
}
export debug = true;
export debugMessage = 'Hello!';
export default do;

// plugin
name: 'Debug plugin',
moduleParsed: async (info) => {
  if (info.exports.debug) {
    console.warn(info.exports.debugMessage);
  }
},

Of course this is just an easy example and not supposed to be something meaningful. I can imagine many use cases of plugins that one could develop accessing a module's exports.

Feature Proposal

Expose a module's and bundles exports in hooks as an object that you can access.

[lukastaegert]

Basically like what we have on chunks, i.e. exports, imports and importedBindings? That would be doable with some caveats. The reason we do not have that yet is that it is sometimes hard to know the actual exports of a module before the build phase is done.

If the module does an export * from 'otherModule', then we likely do not know yet which named exports from the other module are injected in moduleParsed. Which is why we only have hasDefaultExport at this point because star reexports never add a default export, so this is reliable.

I would definitely be open to good proposals and PRs here. Maybe it could also make sense to differentiate between exports and re-exports (something like reexportedBindings?), which could have special syntax for namespace reexports.

[gerardmarquinarubio]

The reason we do not have that yet is that it is sometimes hard to know the actual exports of a module before the build phase is done.

Then we should limit it to "inline" exports that have no dependencies. I don't know what the correct naming for those exports would be (local exports maybe).

If the module does an export * from 'otherModule', then we likely do not know yet which named exports from the other module are injected in moduleParsed. Which is why we only have hasDefaultExport at this point because star reexports never add a default export, so this is reliable.

Parsing of the AST should be done to analyse if the export declaration contains a value in the same file. Something similar to what Nextjs is doing here.

Thanks for your comment, hopefully more people become interested in this. I see so many benefits on adding this and it would add so much value for plugin writers for rollup.

[lukastaegert]

Maybe something like this:

exports: ['foo', 'bar', '*'] // contains some unspecified namespace reexport,
exportedBindings: {
  '.': ['foo'] // or some other way to signify local exports,
  '/some/dependency': ['bar', '*'], // reexported stuff
}

[rollup-bot]

This issue has been resolved via #4731 as part of rollup@3.6.0. You can test it via npm install rollup.