Default linting rules?

[mh1622]

I'm running oxlint with the following config:

{
  "$schema": "./node_modules/oxlint/configuration_schema.json",
  "plugins": ["eslint", "unicorn", "typescript", "oxc", "import", "promise", "vitest"],
  "options": {
    "typeAware": true,
    "typeCheck": true
  }
}

Now I have two questions:

1. This page states that the default built-in plugins are:

• eslint

• typescript

• unicorn

• oxc

  So presumably, I do not need to add those to the plugins parameter. Is that correct? Are these defaults likely to change? Is it actually better documentation to be listing them explicitly, especially to safe-guard in case the default status of built-in plugins ever changes?

2. eslint's no-new rule is implemented in the eslint built-in plugin, which is a default plugin. Why is it then, that I need to add:

"rules": {
  "no-new": "error"
}

to my config in order to get the rule enabled? Shouldn't it be implicitly enabled if it belongs to a default plugin? Clearly, some rules are enabled by default, but seemingly others, that I would have thought should be enabled by default, aren't. I'd prefer to not have to maintain a massive list of rules in my oxlintrc config file.

[webrcost4]

Good questions — there are two separate concepts here that are easy to conflate: plugin availability vs rule activation.

1. Built-in plugins vs plugins field

You’re correct that eslint, typescript, unicorn, and oxc are built-in plugins. In practice:

• You don’t need to list them in plugins for them to be available
• The field is mainly for enabling non-built-in plugins (like import, promise, vitest)

However, explicitly listing them can still be useful for:

• clarity / self-documentation
• avoiding ambiguity for new contributors

As for stability: built-in defaults are unlikely to change frequently, but they are not a hard guarantee. If your goal is config reproducibility, being explicit is safer.

2. Why rules like no-new are not enabled by default

Being part of a plugin ≠ being enabled.

Plugins define available rules, but rule activation depends on presets/configs, not just plugin presence.

So:

• eslint plugin includes no-new
• but unless you extend a preset that enables it, or define it manually, it stays off

This is intentional:

• different teams have different tolerance levels for strictness
• enabling everything by default would be too opinionated and noisy

3. How to avoid maintaining a massive rule list

Instead of enabling rules one by one, the usual approach is:

• extend a preset (if/when oxlint provides stable ones)
• or define a minimal baseline and selectively override

For example, a pattern like:

• start with recommended defaults (when available)
• add a small number of high-signal rules (no-new, no-unused-vars, etc.)
• avoid chasing full parity with ESLint configs unless necessary

---

TL;DR

• Built-in plugins are available without listing them, but listing them can improve clarity
• Rules are not auto-enabled just because the plugin exists
• Use presets or a minimal curated rule set instead of trying to enable everything manually