[MissGwen]

Motivation

Keeping the exports field in package.json in sync with build entries is manual and error-prone, especially for multi-entry or dual-format libraries. #1291 proposes generating it from build outputs.

Changes

Add opt-in exports generation through rslib build --exports, the exports configuration option, and the JavaScript build API. After a successful build, Rslib generates exports for ESM and CJS entries, declaration files, and bundled CSS.

The configuration supports selecting entries, exposing source files for development, and customizing the generated result. Generated exports replace the existing exports field; they are not written in watch mode or when building only selected libs.

The release management guide documents the generation rules and options.

[elecmonkey]

Thank you for your contribution! The team is still discussing and thinking through the implementation approach. We’ll share any updates or continue the discussion here once we make progress!

[MissGwen]

Thank you for your contribution! The team is still discussing and thinking through the implementation approach. We’ll share any updates or continue the discussion here once we make progress!

Thanks for the update! Once the approach is settled, I’d be happy to update this PR accordingly and help with the remaining work in #1291 if needed.

[elecmonkey]

Hi, sorry for delay. I personally agree with the implementation approach. I have a few thoughts on this topic:

1. I would prefer an explicit CLI flag or command instead of a persistent config option, since updating package.json should be intentionally triggered by the author.
2. The update should preserve the existing indentation and formatting, ideally modifying only the relevant fields.
3. Existing unrelated or custom exports entries should be merged and preserved where possible, rather than replacing the entire field.
4. ./package.json probably should not be exported by default.
5. It would be helpful to consider d.ts entries as part of the same design.

Do you have any thoughts or feedback on these points? Would you be open to me continuing the work directly on your PR?

[MissGwen]

Thanks for the detailed review — this is really helpful.

1. I started with a config option based on the API proposed in [Feature]: Add an option to automatically generate exports fields in package.json #1291, but I agree that an explicit CLI flag or command makes more sense. That way, the author chooses when to update package.json.

2. Agreed. The current code rewrites the whole file with fixed formatting. Keeping the existing indentation and line endings would make the diff much cleaner. We could also skip writing if nothing has changed.

3. I agree with keeping custom exports. One thing I’m unsure about is how to distinguish them from stale entries generated by an earlier build, since we don’t currently track that. Could we keep entries we’re unsure about and warn on ambiguous conflicts for now, without trying to clean up old entries automatically?

4. tsdown includes ./package.json by default when generating exports, but I’m happy to leave that choice to the author here. We can stop adding it automatically and keep it if it’s already explicitly exported.

5. I did look into types support earlier, but the DTS plugin doesn’t currently expose the final declaration paths to the exports generator. That would involve changes to the DTS plugin, so I left it out of this first version. I agree it makes sense to consider it together.

And yes, please feel free to continue directly on this PR — maintainer edits are already enabled! I’m quite busy with work at the moment and don’t have much time to continue this myself, so I really appreciate your offer to help.

[CLAassistant]

All committers have signed the CLA.

[MissGwen]

@elecmonkey I've signed the CLA 🥰

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[MissGwen]

I accidentally clicked “Update branch” while looking through your changes, which triggered another CI approval request. Sorry for the extra step😣, and thanks again for continuing the work on this PR!❤️ @elecmonkey