☂️ Linter plugin configuration

[arendjr]

Description

This issue tracks development of plugin configuration for the linter. This is merely about extending our configuration format and settings so that plugins can be configured. The actual loading or executing of plugins is considered out of scope here.

To see how this issue fits into our plugin efforts, please look at the overview here: #2463

How to Contribute

Everyone is welcome to contribute pieces here! If you'd like to tackle something, please leave a comment below this issue for which item(s) of the checklist below you'd like to pick up. We will create a separate issue and assign it to you to simplify tracking.

If you need any help or have any questions about our plugin efforts in Biome, feel free to ask in the #plugins channel in Discord.

Tasks

• Add a linter.rulePlugins section to the configuration.
  • In a first iteration, this can probably be a single array of strings, each being the path to an individual plugin file.
• Implement plugin resolution.
  • We probably want to use oxc_resolver so that package names can be used in place of direct paths to the plugins.
• Extend configuration to include rule options.
  • We can probably take inspiration from how rule options are configured for built-in rules.
  • Keep in mind that the JSON schema cannot verify options for plugins, unlike built-in rules where we know the types.

Discussion

• Do we want support for individual plugins that enable multiple rules? It seems unnecessary for a first release, but there might be advantages to supporting this. A downside would be the configuration would become more complex if we need to be able to enable/disable rules per plugin.

[Conaclos]

We should think about #689. Maybe we can work towards a unified proposal.

[arendjr]

We should think about #689. Maybe we can work towards a unified proposal.

A potential downside of unifying might be that it would be very hard for the schema to validate options for known rules. Not sure if there’s a clever way to avoid that?

[ematipico]

I think plugins deserve a different section in our configuration.

Even though the discussion is about linting, I think we should force ourselves to see the big picture and the future.

What if a tomorrow someone will create a biome plugin for pug that parses, format and lints? I wouldn't expect users to fill three fields (parsing, formatting and lining) just to opt-in a plugin.

We envision just a field, and then Biome will enforce an interface to hook the different tools of the toolchain.

[arendjr]

Even though the discussion is about linting, I think we should force ourselves to see the big picture and the future.

What if a tomorrow someone will create a biome plugin for pug that parses, format and lints? I wouldn't expect users to > fill three fields (parsing, formatting and lining) just to opt-in a plugin.

I can understand where you're coming from, but I'm not sure this is feasible in any near future. To create the kinds of plugins you're proposing means that our full CST structure would need to not only be accessible to plugins, but also able to be defined by plugins. If someone creates a plugin that defines a new language, how would any piece of strictly typed Rust code access the CST defined by that plugin? I have intentionally been trying to keep this out of scope for now, since frankly I don't see this happening within the next 2 years or more (in other words, at least one, but probably multiple major versions from now). If we try to design "everything plugins" from the start, I'm afraid we'll have such feature creep that we won't see the forest for the trees.

[arendjr]

For now, we've settled on a top-level plugins field in the configuration. This is implemented, although the ability to pass options to plugins is not there yet.