Minor improvements of the CLI

[Conaclos]

I've been thinking for a while about a number of minor changes that could improve the CLI experience.
These ideas come from my user perspective and the observation I made when users discover Biome for the first time.

Default to the working directory

The main Biome commands require passing at least one file (possibly a directory).
For instance, to format all files in the working directory, a user has to run biome format ./.

Once a user created the configuration file, it is really likely that it will always run biome format ./ because the configuration file often specifies which files to ignore and/or include.

I propose to relax this requirement by making biome <format|lint|check> an alias of biome <format|lint|check> ./.

Make possible to directly reference the config file with --config-path

Biome allows users to point to the directory of the configuration file to load using the --config-path option.
The option only accepts a directory. This was and still is a source of confusion for users because they are accustomed to directly point to the configuration file.

I believe the intention was to prevent users from using custom names for the configuration file.

I suggest extending the capabilities of the option by allowing users to point directly to the configuration file.
We could maintain the original intent by requiring that the pointed to file use a valid name between biome.json and biome.jsonc.

Some examples of valid arguments:

❯ biome format --config-path=./configs/
❯ biome format --config-path=./configs/biome,json

And some examples of invalid arguments:

❯ biome format --config-path=./configs/custom-name,json 

Alternatively, we could rename --config-path to --config-dir and introduce the --config-file option.

Note: the change should also be propagated to the BIOME_CONFIG_PATH env variable. This also confuse users.

--write everywhere

Biome wants to provide a cohesive experience by making every tool compatible with each other.
Providing a consistent CLI and configuration is important.

By default, CLI commands don't change the source code, but when specific flags are provided.
biome format and biome migrate require --write, while check and lint require --apply or --apply-unsafe.

For the sake of consistency and discoverability I propose to use a unique name for indicating to a command to modify the code.

We could choose between --write, --apply, or --fix.
I could pick --write or --apply to avoid too many changes.
However, --fix is also appealing because it is short, is close to our linter terminology (code fixes).

Here is an example with --write:

❯ biome lint --write .
❯ biome format --write .
❯ biome check --write .
❯ biome migrate --write

What about --apply-unsafe?
I think we could introduce a new flag --unsafe which could be used in combination with --write to apply safe and unsafe fixes:

❯ biome lint --write --unsafe .
❯ biome check --write --unsafe .

It seems cleaner to me to keep a single option to indicate whether to write/apply or not.

[arendjr]

I’m pretty much in favor of all these suggestions :)

Regarding --config-path I’d be in favor of keeping the argument name and letting it accept both files and dirs. It seems simpler from a user-perspective and doesn’t require breaking changes.

Also +1 on using --write everywhere. Combining it with --unsafe makes sense too. I think we should keep the old names as aliases also to prevent breaking changes.

[Sec-ant]

I agree with @arendjr and I'd like to pick up the --config-path enhancement if this is decided.

[ematipico]

These suggestions seem very reasonable.

We should create an umbrella issue to collect all the changes for v2.0.

From where I stand, the next minor - v1.7.0 - will be the last minor before 2.0.

[Conaclos]

All of these changes can be done in a backwards-compatible way. We could keep --apply' and --apply-unsafe' and deprecate them. Removing them might be too early for Biome 2.0 if it is the next relkease after 1.7?

By the way, I am not sure to see why we should hurry up for Biome 2.0?

[ematipico]

By the way, I am not sure to see why we should hurry up for Biome 2.0?

Because I want to remove all the deprecations that belong to Rome

[Conaclos]

Due to positive feedbacks, I will open related issues.