Formalize steps to make a feature request

[kwonoj]

Status	Last Updated	Target version
Accepted	Mar.27.2023	N/A

Summary

Establish searchable historical record for the feature development, or changes for the SWC.

Motivation

SWC gets bigger with lot of new features or changes. This is something expected since SWC is a core building block for the JS toolchain and each users have workflows may require support from SWC. We'd like to introduce thin template to track those to let core team member understands background, also keeps historical record in case we need to look for.

Detailed design

Proposal template

| Status  | Last Updated | Target version |
| ------------- | ------------- | ------------- |
| `Draft | Open | Accepted | Rejected`  |   | `x.y.z | TBD | N/A` |

# Summary
// Couple of lines of the summary what this feature will do

# Motivation
// Reason why SWC need to implement, or change behavior for this

# Detailed design
// Explain the design in enough detail, including code examples

# Drawbacks
// Why should we not do this? Please consider:

- implementation cost, both in term of code size and complexity
- whether the proposed feature can be implemented in user space
- integration of this feature with other existing and planned features
- cost of migrating existing codebase (is it a breaking change?)

# Alternatives

# Unresolved questions

# References (if exists)

This is largely borrowed from https://github.com/reactjs/rfcs/blob/main/0000-template.md, there were couple of existing proposal based on this (#3065)

Proposal process

1. Write a proposal under https://github.com/swc-project/swc/discussions, with new category (Proposal? Feature request?)
2. Change status to Open if it's ready to discuss
3. Depends on the discussion, if it's accepted swc will implement
4. Once proposal completes, either accepted or not, will commit plain text under https://github.com/swc-project/swc/tree/main/docs/rfc

It is possible once rejected feature can be reconsidered over time due to various reasons. A new proposal based on previous proposal describes what's been changed will be required.

Proposal (RFC) vs. ADR

SWC keeps track of architecture decision record (https://github.com/swc-project/swc/tree/main/docs/adr) already. It serves slightly different to feature proposal does. We write ADR when

• If SWC implemented, or changed its behavior
• If SWC decided to not to do something

It actually overlaps lot though. In most cases for the new features, we may end up having a RFC and ADR both. But in case of ADR it'll include more of implementation details while actually implementing RFC. Plugin ADR is a good example (https://github.com/swc-project/swc/blob/main/docs/adr/00001-support-transformation-plugin-native.md).

What can go @SWC/Core vs. not

There is ongoing effort to support plugin (#3540) which can makes most of custom features into userland. SWC's core team want to utilize this as much. However, as of today it is not fully stablized to encourage to write plugin for any custom features. For those reason this proposal does not cover to categorizing what feature request should go for the core or not.

[kwonoj]

It's been a while since this proposal was written, and I personally don't see major flaws in the proposal itself. There may be minor issues or improvements, but I think these can be addressed over time after implementation. Thoughts on trying this @kdy1 ?

If we try this one, probably rough flow looks like this

• if adding a new api surface (either rust / js bindings) will need to write RFC and discuss

• if there's a breaking changes suggestion for the api surface will need same

• New PR without feature proposal discussion will not be accepted

• For the fix around unexpected behavior RFC won't be needed

• There may be some edge cases, we'll discuss ad-hoc for those per each item

[kdy1]

I love this idea. Let's try this.