feat(cli): alias --unstable-sloppy-imports to --sloppy-imports

[kingsword09]

closes: #29705
Alias --unstable-sloppy-imports to --sloppy-imports

[anonhostpi]

Why? What does this achieve? There's no documentation on #29705

[anonhostpi]

Are you trying to bypass the review process of making an unstable flag seem stable?

[bartlomieju]

Are you trying to bypass the review process of making an unstable flag seem stable?

What makes you say that this contributor is trying to bypass a review process? There's no formalized review process to stabilize a flag and it's at the discretion of the core team to do that.

[anonhostpi]

Nothing, I was just scrutinizing the quality of the PR. At a surface-level this appears to have qualities of an XZ-utils attack. Not saying that it is, just asking why it has been set up that way.

[bartlomieju]

There's not much else to do when stabilizing a flag - it's really just flipping a value.

[anonhostpi]

I mean ultimately up to you dog, if you trust this contributor, go for it.

The lack of documentation on this ticket or the cited one when discussing unstable features is a red flag.

To be clear, I'm not saying it is one way or the other, just at the surface, looks questionable.

[kingsword09]

I just saw that there was an issue and thought I'd try to contribute.

[dsherret]

LGTM! Thanks for the PR, @kingsword09

We'll merge this one for the 2.4 release (I skipped approval for now and will merge once we're done doing patch releases for 2.3)

[nayeemrmn]

It's strange that the config file (preferred?) equivalent is still 'unstable'. There should be a "sloppyImports": true deno.json field to go with this.

[bartlomieju]

It's strange that the config file (preferred?) equivalent is still 'unstable'. There should be a "sloppyImports": true deno.json field to go with this.

I literally had the same revelation 15m ago. We also discussed features field in the past. Not sure if we should do this stabilization in this release.

[nayeemrmn]

Some arguments for top-level keys "sloppyImports": true as opposed to "features": ["sloppy-imports"]:

• Most experimental features are stabilised by making them enabled unconditionally. There won't/shouldn't be many settings like this.
• Having both "unstable": [] and "features": [] would feel confusing and redundant, yet renaming unstable to features wouldn't communicate instability.
• Usual alignment with the --sloppy-imports flag. You wouldn't have to check the docs to infer one syntax from the other.

[dsherret]

I agree about adding a sloppyImports: true top level config. It also makes it more discoverable and allows flipping the default in the future.

[dsherret]

LGTM