📎 Consider disabling all lint rules by default

[sebmck]

[jamiebuilds]

Just a quick note from our conversation

We can have flags for easily turning on different rulesets:

{
  "rome": {
    "lint": {
      "recommended": true
    }
  }
}

[ljharb]

Why? What good are lint rules if they're not on by default?

[jamiebuilds]

"Turned off by default" is probably the wrong answer. I would prefer turned on by default, but have everything turned off as soon as you started providing config with a simple way to get turn the base recommended stuff on.

[ljharb]

Gotcha, that makes sense - meaning, the default config is not "an empty object", it's "something like in your previous comment".

[jamiebuilds]

Maybe something like this:

{
  "rome": {
    // no linting
    "lint": false,
    // recommended rules
    "lint": true,
    // react rules
    "lint": { "rules": { "react": true } },
    // recommended+react rules
    "lint": { "rules": { "recommended": true, "react": true } },
  }
}

[jamiebuilds]

Some more thoughts:

• Everything is divided into rules
• Rules are grouped into categories (ie js, html, react)
• Categories can be recommended (i.e. js is recommended, but react is not)
• Rules can be recommended within their category (i.e. noDirectMutationState is recommended within react)

So we'd have metadata about the rules that looks like:

const Rules = {
  a11y: {
    recommended: true,
    rules: {
      noAccessKey: {
        recommended: true,
      },
      noAriaUnsupportedElements: {
        recommended: false,
      },
    },
  },
  react: {
    recommended: false,
    rules: {
      noArrayIndexKey: {
        recommended: false,
      },
      noDirectMutationState: {
        recommended: true,
      }
    },
  },
  // etc...
} as const

That would work like this:

{
  "rome": {
    // turn linting off (default)
    "lint": false,
    // turn linting on
    "lint": true,
    // turn linting on, but customize it
    "lint": {
      // customize the rules (default: `{ "recommended": true }`)
      "rules": {
        // turn recommended categories off
        "recommended": false,
        // turn recommended categories on
        "recommended": true,
        // turn a specific category on (overriding `recommended`)
        "react": true,
        // true a specific category off (overriding `recommended`)
        "a11y": false,
        // turn a specific category on, but customize it
        "a11y": {
          // turn recommended rules off
          "recommended": false,
          // turn recommended rules on
          "recommended": true,
          // turn a specific rule on (overriding `recommended`)
          "noArrayIndexKey": true,
          // turn a specific rule off (overriding `recommended`)
          "noDirectMutationState": false,
        }
      }
    }
  }
}

Some examples:

Turning on the recommended categories:

{
  "rules": { "recommended": true },
  // expands into:
  "rules": { "a11y": true, "react": false },
  // expands into:
  "rules": { "a11y": { "recommended": true }, "react": false },
  // expands into:
  "rules": { "a11y": { "noAccessKey": true, "noAriaUnsupportedElements": false }, "react": false },
}

Turning on the "react" category:

{
  "rules": { "react": true },
  // expands into:
  "rules": { "a11y": false, "react": true },
  // expands into:
  "rules": { "a11y": false, "react": { "recommended": true } },
  // expands into:
  "rules": { "a11y": false, "react": { "noArrayIndexKey": false, "noDirectMutationState": true } },
}

Turning on the "react" category with specific rules:

{
  "rules": { "react": { "noArrayIndexKey": true } },
  // expands into:
  "rules": { "a11y": false, "react": { "noArrayIndexKey": true } },
  // expands into
  "rules": { "a11y": false, "react": { "noArrayIndexKey": true, "noDirectMutationState": false } },
}

[ematipico]

I like this configuration.

My only concern is how big a configuration file might become (test, lint, bundling, etc.). Maybe, in the future, we might think of a way to splitting it.

[sebmck]

The extends property allows you to specify an array so you can already get the splitting functionality with:

{
  "extends": ["./rome-test.json", "./rome-lint.json"]
}

I think the natural argument is why not support dynamic configuration via a rome.js file but that's a whole other can of worms.

[ematipico]

Oh nice! I didn't think about it! Then problem solved