feat(oxlint-config): add oxlint config

[lld4n]

Add basic oxlint config. During the implementation of the configuration, I used the rules settings from eslint-plugin-experience-next (recommended) and only those rules that are already ready in oxlint

Test oxlint config in taiga-ui

Usage	Time
eslint	124.78s
eslint + oxlint	62.29s(eslint) + 0.89s(oxlint)

I think the basic idea of the following steps is:

• simplify the configuration of the oxlint config
  • when updating the oxlint library, semi-automatically detect new rules and the need to enable them based on eslint-plugin-experience-next
  • when updating eslint-plugin-experience-next, semi-automatically detect the changed rules for oxlint
• try to untie the oxlint config from the eslint config
  • try to enable js plugins - https://oxc.rs/docs/guide/usage/linter/js-plugins.html
  • define the missing rules for the complete abandonment of eslint
  • rewrite custom taiga-ui eslint rules in rust for oxlint support
  • enable oxlint config on github ci in this repository

Fixes #1474

[connorshea]

FWIW, based on the logs from https://github.com/taiga-family/toolkit/actions/runs/20557598294/job/59043899936?pr=1475 I think you could use the import/no-cycle rule from oxlint and save a ton of time? https://oxc.rs/docs/guide/usage/linter/rules/import/no-cycle.html

[splincode]

Can we automate this? Generate configs from our eslint config?

[lld4n]

Yes, you can use oxlint-migrate. However, it produces a more complex configuration file, as it completely duplicates the eslint settings.

https://github.com/oxc-project/oxlint-migrate

[lld4n]

why didn't I use the config that is generated in oxlint-migrate?:

• The complexity of the resulting configuration: automatic migration honestly turns the eslint config into an oxlint config. this means that the oxlint config will be divided into file patterns. This is unnecessary work for oxlint because the rules are automatically applied to the correct file extensions.
• In the following steps, I indicated that can try to enable jsPlugins, but they do not migrate using oxlint-migrate, so will have to register them manually and it will be problematic to make automatic migration completely.

[splincode]

@lld4n Can we partially implement a migrator at the CI level somehow? So that we don’t have to copy-paste rules from eslint-plugin-experience-next, because they may change often (or not so often). In any case, I’m happy to hear any suggestions.

[lld4n]

I don't think it's worth writing a full-fledged config generator from eslint to oxlint, as it would take a lot of time and the result would not be as useful as it seems at first glance. But there is a solution that should theoretically be useful. First, make the oxlint config backward compatible with the eslint config. When changing any file from eslint-plugin-experience-next, define a list of rules that have changed. Use the resulting data to change the oxlint config. Also, keep an eye on oxlint updates and determine which rules they have managed to implement in Rust in order to abandon jsPlugins whenever possible. 

So, as I understand it, the plan is as follows:

1. Merge the current PR so that people can test the configuration on their projects
2. Complete the config using jsPlugins
3. Implement a script to identify differences in rules in eslint configurations and update oxlint based on this data
4. Implement a script to identify new features in oxlint and update oxlint based on this data

[splincode]

@lld4n Could you please rebase?

[pumano]

would love to test that config in our project