📎 Sorting imports as unstable feature

[ematipico]

Description

From discord discussion: https://discord.com/channels/678763474494423051/895012159011053599/962364285177176104 and forward.

We as a team decided to implement this feature as unstable and only opt-in via option. This is because it might break people's code, and as for that we want to make sure to release a feature that doesn't break all people's code.

As it's unstable, there are two course of actions:

• it will be stabilized and made it as a default after possible fixes and feedback
• it will be removed if we think if it bring more harm than advantages

[MichaReiser]

I wouldn't implement this feature as unstable but rather have different presets:

• stable: Default
• experimental: Includes all experimental features. Can be enabled by a single --experimental flag that opts you in into ALL of rome's experimental features.

Only having two presets greatly simplifies the combinations that must be tested.

I'm still having some concerns about the priority of this feature compared to supporting other languages and fixing Prettier incompatibilities.

[ematipico]

experimental: Includes all experimental features. Can be enabled by a single --experimental flag that opts you in into ALL of rome's experimental features.

I am not sure this is safe. As a user, I would like to know what unstable features/experiments I want to try, so giving a finer control might make users happy.

Also, let's say we decided to make an experiment official (e.g. 1 out of 5 that we currently have), how do you plan telling the user that now something is stable and they don't need to use the experiment anymore?

That's why I think each experiment should be opted-in singularly.

I'm still having some concerns about the priority of this feature compared to supporting other languages and fixing Prettier incompatibilities.

Fair, at least we have a placeholder here and resume the works once we're happy.

[MichaReiser]

Also, let's say we decided to make an experiment official (e.g. 1 out of 5 that we currently have), how do you plan to tell the user that now something is stable and they don't need to use the experiment anymore?

I guess it's worth discussing how we want users to use experimental features and what guarantees we give them:

• At what point are we allowed to remove a feature? Is it ok to remove an experimental feature as part of a patch release? What does that mean if experimental features use explicit flags?
• How do we want to make people aware that an experimental feature has now stabilized?
• How do we explain our users that there used to be an option to enable/disable an experimental feature but there won't be such an option once the feature is stabilized?
• How do we avoid increased complexity by having to test for all possible combinations of experimental features?

I think these are questions that we should answer before rolling out any experimental feature.

One reason why I would favor a single experimental flag is that it's the simplest solution to start with and it can be extend to have different flags per feature. I believe the other way, merging all experimental flags into a single flag will be harder to do.

[mattmarcello]

any updates here? I understand the complexity around reordering imports given possible side effects but I would like to opt in if possible.

[ematipico]

any updates here? I understand the complexity around reordering imports given possible side effects but I would like to opt in if possible.

At the moment Rome doesn't have a wait to opt-in unstable features and, as a team, we haven't come up with a strategy to do so because it's not on the top list of our priorities.

I am going to close this issue for the time being, because we don't have the infrastructure to provide these experiments. We will discuss again the topic once we have some time to work on it.