feat(cli): Load browserslist configuration if no --targets supplied.

[LeoniePhiline]

Fixes #293
Fixes #281

[LeoniePhiline]

@devongovett

This PR introduces browserslist configuration auto-discovery. ⚡

The changes are pretty straightforward, as browserslist-rs already perfectly mirrors the nodeJS browserslist behavior.

I chose to require a negative boolean flag --disable-browserslist to facilitate the former targets = None setup.

This allows the preserve_custom_media CLI integration test to pass with an added --disable-browserslist option, while being the most ergonomic for basically everyone else:

I am convinced that the vast majority of users is going to want to use browserslist - with either configuration discovery or at least the built-in defaults.
Therefore, providing the possibility to opt out appears to be the most beneficial choice, as compared to requiring almost all users to opt in.

However, this could be considered a breaking change needing a major semver bump.

If you prefer to stick to 1.x right now, then I will change the browserslist auto-config feature from opt-out to opt-in by requiring a --browserslist flag, without which the CLI would exhibit the same behavior as before.

Please let me know what you prefer!

Detail question:
Do you want --(disable-)browserslist and --targets to share an ArgGroup and be (enforced) mutually exclusive?

[LeoniePhiline]

Thank you for your review!

I will switch from opt out to opt in to keep the change non-breaking.

I'll also need to write some CLI integration tests for browserslist config discovery and browserslist defaults (where opted in).

[LeoniePhiline]

Latest changes (cb9a3e6)

• The feature is opt-in via the --browserslist option, as not to break existing setups.
• The options --browserslist and --targets <TARGET> are now mutually exclusive, as enforced by clap.
• Browserslist integration is advertised more prominently than before, in the README.md features list.
• CLI integration tests were added, testing and documenting the various supported ways of configuration provision and discovery.

Observations these changes were based on

Browserslist config auto-discovery's unwanted effect on tests, as well as potential CLI users:

• In CLI integration tests, where no --targets option was used, specifically the preserve_custom_media test, the browserslist config discovery found and read from lightningcss' own package.json file, containing a browserslist section. I had initially had the misconception that this test failed because browserslist defaults were applied, but later realized the configuration had been read from package.json .
• This effect could apply to many unsuspecting users: They currently run lightningcss without --targets option, yet they do have browserslist configuration in $CWD or an ancestor directory - used by other tools in the same project or even for personal use in their $HOME directory. Enabling the browserslist config discovery feature by default would mean to silently change these users' transpilation output. Therefore browserslist config discovery must be introduced as opt-in, lest it be a breaking change.
• The --browserslist option must be advertised, as it must be enabled manually before use.

Handling caveats in tests where browserslist config auto-discovery is enabled:

• To circumvent the "accidental config discovery" issue in our tests, whereever we want to have --browserslist enabled, we must set the working directory for CLI integration tests to be a temporary directory (as created by assert_fs) rather than the project root directory.
• This is not bullet proof: Commonly the temporary directory's ancestor directories we have no power over. E.g. as assert_fs::NamedTempFile::new() creates a randomly named temporary folder like /tmp/.tmpx1LOGu/, browserslist might discover configuration files in its parent folder /tmp/ if there happen to be such files for any possible reason. In Windows environments, the "Temp" folder might be located within %USERPROFILE% and have a long list of ancestor directories possibly containing browserslist configuration.
• In CI, /tmp should be clean when running in a fresh container; thus tests will be reliable despite the above caveat.
• Another side effect inductor is environment variables: For CLI integration tests which enable the configuration auto-discovery code path we must clear the environment. (At least BROWSERSLIST, BROWSERSLIST_CONFIG, NODE_ENV and BROWSERSLIST_ENV.)
• You will see cmd.current_dir() and cmd.env_clear() used in all browserslist-enabled CLI integration tests.

---

@devongovett Ready for renewed review.

[devongovett]

Thank you, this looks great!

[LeoniePhiline]

Thanks @devongovett - this means a lot to me.