Support "exports" field in package.json

[tetsuharuohzeki]

• Rollup Plugin Name: @rollup/plugin-node-resolve
• Rollup Plugin Version: 7.1.1

Feature Use Case

Bundle a package seamlessly which provides exports` field as an entry point.

Feature Proposal

The exports field has been added to package.json to define an encapsulating entry points for Node.js ES Module supports.
https://nodejs.org/api/esm.html#esm_package_entry_points

This feature has been unflagged from Node.js v13.7. and I seem that this was backported to v12.16.

[shellscape]

Thanks for opening a new feature request. This looks like it would be a significant amount of work to add support for.

I'd like to get a link added to a specification for this issue, but I cannot find any.

@lukastaegert this is a new development

My vote is to hold off until all LTS Node versions support this. That is not currently the case.

[lukastaegert]

I agree. Nevertheless I recently stumbled across this myself, and I think we should start putting some thought into this soon, because it does not only have implications for node-resolve but also for commonjs. Basically this enables specifying different entry points for ESM imports and CJS requires. It would however be unclear, if and how the commonjs plugin would pick this up as well.

[tetsuharuohzeki]

I'd like to get a link added to a specification for this issue, but I cannot find any.

I seem this specification is defined in Resolver Algorithm section.

[mattpilott]

I just ran into a scenario where i'd need this, good to see it's already on the cards

[SupremeTechnopriest]

Node 13 no longer requires a flag to use these features. Can we unfreeze this issue and start work on adding support? Node 14 (next LTS) is due to hit at the end of the month. It would be nice to get ahead of this. The workaround is really sloppy.

[shellscape]

Possibly behind a feature flag. But I don't think we can roll out full support until Node 10 and 12 fade away. And the current Maintenance period for Node 12 is bananas long.

[SupremeTechnopriest]

Possibly behind a feature flag. But I don't think we can roll out full support until Node 10 and 12 fade away. And the current Maintenance period for Node 12 is bananas long.

Sounds good to me!

[jkrems]

If nodejs/node#32869 lands, this likely should include support for NODE_ENV based resolution ("production" and "development").

[MylesBorins]

@shellscape curious why you think that we would need to wait until Node.js 12 EOL. We do plan to remove both the flag and the warning before it moves into maintenance mode.

[lukastaegert]

Personally I would also like to see movement here once this is unflagged, but there ARE some open questions to answer:

If a package uses conditional exports, such as Rollup itself, then currently resolution can be VERY different between Node 12 and Node 13+. So how should we play this?

• ignore them for Node <= 12 but observe them for Node 13+? This would make builds non-portable between those Node versions.
• Add a flag to configure if they are obeyed. I think considering the previous point, we should DEFINITELY put this behind a flag until Node 12 is EOL, at which point we can consider deprecating the old mode.

Moreover, how should this interact with our current "special" resolution aka "mainFields"? What should the precedence order be, or rather, how do we want to configure it? This would require some serious thought to get right.

And last note that this will be one of the biggest additions to this plugin ever. For our current logic, we heavily rely on https://github.com/browserify/resolve. The question is if we roll the conditional exports logic on our own on top of that (I fear we must if we want to be able to configure priorities) or if there is a way to reduce maintenance overhead as we try to stay abreast of extensions to this feature.

So understand if we tread cautiously here.