chore: switch from browserslist-rs to oxc-browserslist

[cijiugechu]

Description:

oxc-browserslist is a fork of browserslist-rs with improved performance, actively maintained by oxc-project. The following are the changes made to it after the fork:

• reduced compilation speed from one minute to a few seconds
• removed all unnecessary, heavy or slow dependencies: ahash, chrono, either, indexmap, itertools, once_cell, string_cache
• improved some runtime performance, e.g. improve sort method, precompute versions

BREAKING CHANGE:

Related issue (if exists):

[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]

@g-plane Thoughts?

[g-plane]

oxc-browserslist generates browserslist data into .rs files and they commit them into Git, while browserslist-rs uses build.rs to generate files to target directory at compilation time. That's the biggest difference.

[kwonoj]

• would like to know if there's a reason to choose fork instead of upstream, at least wasn't able to see discussion around upstream repo.

[g-plane]

If using Browserslist is not a hot path of SWC, this change is subtle. (Optimization should be considered for hot paths first.)

[cijiugechu]

Considering that swc is the upstream repository for many projects, even minor changes can benefit many downstreams.

[kwonoj]

That applies if any upstream / downstream packages rely on swc also switch their dependency / transitive dependencies to this forked pkg, isn't it? While the implication might not be measurable, that'll take a longer way than if upstream adapts some improvements. As shared above, would like to understand why fork has to be created.

[kdy1]

I think the improvement of the compile time is important difference, but I want to hear about the reason of creating a fork instead of sending a patch to original project