Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PoC] V2 API changes using cargo feature flag #5536

Closed
wants to merge 3 commits into from

Conversation

kdy1
Copy link
Member

@kdy1 kdy1 commented Aug 17, 2022

Description:

We can use multi-branch but I think it will really hurt rust-side users.
With multi-branch approach, we have to prevent some patches from being published to crates.io, but I think it's not acceptable for some rust-side users.

So I'm suggesting another approach. We can use a (potentially private) feature flag named swc_v2 in js-surfacing crates like swc or swc_node_bundler to 'hide' some changes to node api.

This is clearly not additive, and that's why I think it should be a private feature.
As users are not expected to depend on swc_v2, enabling it from outside of SWC may break the whole dependency tree, but it's fine.

For PoC, I fixed #5527 only for v2.

I want to hear more about opinions about this approach

Some constraints

  • rust users should not depends on swc_v2. This is not considered as a public api.

  • All code should be accessible witthout swc_v2.

But altering behavior is fine.
Let's say, we want to fix #5535 in v2 and change the order of plugins to after resolver but before decorator or typescript::strip. In this case we can use #[cfg(feature = "swc_v2")] and #[cfg(not(feature = "swc_v2")] respectively.

Related issue (if exists):

@kdy1 kdy1 added this to the Next major milestone Aug 17, 2022
@kdy1 kdy1 self-assigned this Aug 17, 2022
@kwonoj
Copy link
Member

kwonoj commented Aug 17, 2022

At this point, I think we'll probably need to try couple of different approaches to find what's best to suit our needs. Branch, features both have pros and cons and probably one approach will not fulfill most of our needs. The way I'm thinking is probably we'll use feature for the additive (i.e new things on top of sharable), and branch for the change / remove. Some of questions regarding feature-based major is some cases like if involved change requires to keep lot of repeated code with small amount of changes, or how to control deeply transitive dep's (i.e core -> A -> B -> C -> D and we need change D, whereas A / B/ C potentially have D as well), or something else.

Double clarify this is not an objection, just saying we probably need to collect real world challenges before make a firm decision on one end.

@kdy1 kdy1 closed this Aug 19, 2022
@kdy1 kdy1 deleted the poc-v2 branch August 19, 2022 06:53
@swc-project swc-project locked as resolved and limited conversation to collaborators Oct 16, 2022
@kdy1 kdy1 removed this from the Next major milestone Aug 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Remove minification apis from transform()
2 participants