Common format to specify a type or value as a rule option?

[JoshuaKGoldberg]

Forking discussion from typescript-eslint/typescript-eslint#5271 here. There are quite a few times when users have a real need to change or disable a rule for specifically some package exports:

• Enhancement: @typescript-eslint/no-floating-promises should Ignore node 18's built-in test function typescript-eslint/typescript-eslint#5231: At least the new built-in node:test runner intentionally returns ignorable Promises from its test() method that can be ignored by the rule
• The allowedNames option from @typescript-eslint/explicit-module-boundary-types
• The typesToIgnore option from @typescript-eslint/no-unnecessary-type-assertion
• The allowedPromiseNames option from @typescript-eslint/promise-function-async
• Proposed: [no-unnecessary-condition] ignore array index return typescript-eslint/typescript-eslint#1798
• Proposed: feat(eslint-plugin): [prefer-readonly-parameter-types] added an optional type allowlist typescript-eslint/typescript-eslint#4436

I'm not as familiar with the core ESLint rulesets, and didn't see any rules with relevant options in the first few dozen on eslint.org/docs/latest/rules. Nor did I find much about 'name' options in the issue tracker. So I don't know if this type of format is only applicable on TypeScript-land. Has there been much of a demand for it in ESLint core?

Either way - is this something the ESLint team wants to have input / collaboration on?

Edit: The current proposal is now described in the OP at typescript-eslint/typescript-eslint#6017. Copying its summary here...

The current proposal is for specifying the following types of sources, in increasing order of distance from a line of code:

• File: the current file or another specific file in your package (often exported as a module, but not necessarily)
• Lib: globals such as from lib.d.ts or lib.dom.d.ts
• Package: an export from a package, such as "lodash"

Additionally, you can specify multiple of these at the same time with type many.

interface FileSpecifier {
  from: "file";
  name: string | string[];
  source?: string;
}

interface LibSpecifier {
  from: "lib";
  name: string | string[];
}

interface PackageSpecifier {
  from: "package";
  name: string | string[];
  source: string;
}

interface ManySpecifiers {
  from: EntitySpecifierFrom[];
  name: string;
}

type EntitySpecifierFrom = "file" | "lib" | "package";

type EntitySpecifier =
  | string
  | FileSpecifier
  | LibSpecifier
  | PackageSpecifier
  | ManySpecifiers;

For example:

"@typescript-eslint/no-floating-promises": ["error", {
  "ignore": [
    "from": "package",
    "name": "test",
    "source": "node:test"
  ]
}]

[JoshuaKGoldberg]

@SlickNet - at mentioning you as suggested on Twitter. Is this something you want to weigh in on?

If not, that works for me; we can go with the current proposal. I just don't want to move forward with something and later realize it doesn't play well with something in ESLint core. 🙂

[JoshuaKGoldberg]

Sure, sorry for the wall of links. In short, I'm proposing we standardize a way to describe a type or value in rule options.

Reasoning: we get a lot of requests for disabling rules for specific types or values. For example, typescript-eslint/typescript-eslint#5231 requests the ability to disable @typescript-eslint/no-floating-promises specifically on the test function imported from node:test. It'd be best to disable the rule only for that test function - not any other function that happens to be named test.

Here's how the configuration might look:

"@typescript-eslint/no-floating-promises": ["error", {
  "ignore": [
    "from": "package",
    "name": "test",
    "source": "node:test"
  ]
}]

And here's a TypeScript description of the format I'm proposing:

interface FileSpecifier {
  from: "file";
  name: string | string[];
  source?: string;
}

interface LibSpecifier {
  from: "lib";
  name: string | string[];
}

interface PackageSpecifier {
  from: "package";
  name: string | string[];
  source: string;
}

interface ManySpecifiers {
  from: EntitySpecifierFrom[];
  name: string;
}

type EntitySpecifierFrom = "file" | "lib" | "package";

type EntitySpecifier =
  | string
  | FileSpecifier
  | LibSpecifier
  | PackageSpecifier
  | ManySpecifiers;

[nzakas]

Ah I think I understand now. It would be helpful to see some examples of current ESLint core rules where you envision this being used, just to ground the proposal in reality for the team.

[JoshuaKGoldberg]

I don't stand by the API design or compatibility with existing rule options of these mockups 🙂 ...

• class-methods-use-this > exceptMethods: "Block class methods that don't use this except for methods that extend from *Factory* classes in ./factories/*"

  "class-methods-use-this": ["error", {
      "exceptMethods": [{
          "from": "file",
          "name": "./factories/*",
          "source": "*Factory*"
      }]
  }]

• no-new: "Block floating news except for classes exported by some-old-dependency"

  "no-new": ["error", {
      "except": [{
          "from": "package",
          "name": "some-old-dependency",
      }]
  }]

• no-restricted-properties: "Block the dangerous property only from classes exported by ./legacy/*"

  "no-restricted-properties": ["error", {
      "rules": [
        {
            "object": {
                "from": "file",
                "name": "./legacy/*",
            },
            "property": "dangerous"
        }
      ]
  }]

[nzakas]

Thanks, this is more crystalized in my mind now. So, here's the problem as I see it: changing the schema for existing rules to match a preferred format doesn't make much sense. It just creates instability with no end-user value. And given that we add very few rules to the core on an ongoing basis, I'm not sure how useful it is to come up with a standard that may or may not apply in the near future.

So, in my opinion, you should feel free to come up with a standard way to do this in typescript-eslint rules, but I don't know that it makes much sense to come up with one for ESLint core.

[JoshuaKGoldberg]

Got it, thanks! I'll consider this thread resolved.