Oxlint plugin

[KubaJastrz]

Hi, we're looking to migrate from eslint to oxlint for faster linting. Do you plan to make an oxlint plugin for lingui?

I also don't see any discussion in oxc repo https://github.com/oxc-project/oxc/discussions?discussions_q=is%3Aopen+lingui

I can help with building it / prepare an initial version if you want :)

[andrii-bodnar]

Hi @KubaJastrz, thanks for raising this! I'm converting this issue to a discussion, since it's a direction question rather than an actionable item at this point.

This has come up a few times already (including requests for a Biome equivalent), but we don't have a solid position yet. The main concern is maintenance - a dedicated Oxlint (or Biome) plugin means a second rule set that has to be kept in sync with the ESLint one.

Oxlint's JS plugins (https://oxc.rs/docs/guide/usage/linter/js-plugins) (alpha since March) aim to be compatible with the ESLint v9 plugin API, so most ESLint plugins should work under Oxlint as-is. That might make a dedicated port unnecessary. If you get a chance to try running @lingui/eslint-plugin through it, I'd love to hear how it goes - that feedback would help shape the decision here.

[mikavilpas]

I switched to oxlint and am using this plugin as a JS plugin there. 🤞🏻

It seems to work fine! The only things that could make sense (just ideas, I'm not familiar with this project!):

• opt into the more performant "alternative api" described in https://oxc.rs/docs/guide/usage/linter/writing-js-plugins.html
• add CI integration testing for both eslint and oxlint
• declare it as officially supported

[andrii-bodnar]

Thanks @mikavilpas, it's great to hear it works out of the box!

So, we can avoid creating a separate Oxlint plugin and instead document it as officially supported, plus add a CI job that runs the rules under Oxlint as well. Would you be open to contributing this within the current repo and the Lingui docs?

The alternative API looks reasonable. The trade-off is @oxlint/plugins becoming a runtime dependency and moving per-file state into before hooks, so I'd treat it as a separate follow-up once the CI job is in place.

[mikavilpas]

Glad it seems like a possible path. I'm afraid I don't have the capacity to do it though, but will follow this discussion in case something comes up.

[andrii-bodnar]

Just pushed #151. @mikavilpas @KubaJastrz what do you think about it?