Assess an Rspack API

Scope and outcome

Decide whether Rspack should add or keep a proposed API, including a hook, from Rspack's own architecture. Accept a PR, issue, commit, symbol, or design proposal and answer:

1. What does it do inside Rspack?
2. Which concrete scenario needs it?
3. Can existing Rspack capabilities replace it, and how?
4. What is its performance impact?
5. What is its architectural impact?
6. How is the analogous webpack API used?
7. Should Rspack add or keep it?

The final verdict must always include its reasons. State why the user and compatibility value does or does not outweigh the best substitute, performance cost, and long-term architectural commitment; never return only “add” or “do not add”.

Apply a strict public-API budget: the proposal carries the burden of proving that a permanent extension surface is necessary. If an existing Rspack solution can satisfy the required behavior correctly, reject the new API by default even when the substitute is later, less convenient, or requires rewriting one or a few plugins. Make an exception only when verified ecosystem evidence shows compatibility gains for a substantial set of independently maintained and actively used plugins; theoretical webpack parity, one consumer, forks, and copied implementations are insufficient.

This is read-only unless the user separately requests implementation or publication. Do not post comments or mutate GitHub state as part of the assessment.