fix(preset-env): Consider browserslist config if env.target not configured

[egfx-notifications]

Description:

The env.path option in .swcrc was originally implemented for browserslist, but implementation was (unintentionally?) removed during the migration to browserslist-rs (#2845). Searching the current directory for browserslist configuration was also dropped in the process.

This PR reimplements searching for browserslist configuration using the lookup functionality provided by browserslist-rs

BREAKING CHANGE:

This may be considered a breaking change since the previous (broken) behavior for unconfigured env.targets was to return a BrowserData struct with all Options set to None. Now the result of a browserslist defaults query is returned instead. This probably was the original behavior with browserslist, though. Update: Thinking about it again, targets_to_versions() is part of preset_env_bases public API so we should probably consider this a breaking change anyway.

Things to consider:

• only works for non wasm targets as browserslist-rs does not provide configuration loading for wasm32 targets (which is probably to be expected that we won't check environment variables or search a filesystem in that case)
• feat(preset-env): Let browserslist-rs handle default config path changes the default for an unconfigured env.path from an empty string for wasm targets / current dir for other targets to a None value. browserslist-rs already looks up the current dir if path is None and it felt better to let it handle this case itself The commit which migrated from browserslist to browserslist-rs mentioned fixing the default_path, but does not mention what was broken and I also did not find any other usage of the path property. If the previous implementation was intentional, just ignore that last commit in the PR, the first two sufficiently address the bug.

Related issue: Fixes #3365 Implements #3085

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: 7a7aaf8f76976f054ddefa4c080c65b65f163ef1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[kdy1]

cc @kwonoj

[egfx-notifications]

It seems some of the tests fail due to them expecting a specific prerecorded results, but this result has now changed due to the previous default without a target being BrowserData with only None values and now it is BrowserData according to browserslist-rs defaults query, so some stuff that browser now understand natively is not transpiled.

Seems forcing a browserslist query when target is none is not the best approach. I won't try any fixes before hearing your feedback on how to handle this. Should we make the env.path option mandatory if a browserslist config lookup is desired?