Help configuring useNamingConvention?

[wojtekmaj]

Hey,
I would like to recreate behavior of my previously set up ESLint rules:

    "@typescript-eslint/naming-convention": [
      "error",
      { "selector": "default", "format": null },
      {
        "selector": "typeAlias",
        "format": ["PascalCase"],
        "prefix": ["T"]
      }
    ],
    "id-length": [
      "error",
      { "min": 2, "exceptions": ["y", "z", "_"] }
    ]

So basically:

• Forbid one-character variable names,
• Force types to be prefixed with T.

Here's what I got so far in biome.json:

        "useNamingConvention": {
          "level": "error",
          "options": {
            "strictCase": false,
            "conventions": [
              {
                "selector": {
                  "kind": "typeAlias"
                },
                "match": "T.{2,}",
                "formats": ["PascalCase"]
              },
              {
                "selector": {
                  "kind": "typeParameter"
                },
                "match": ".*",
                "formats": ["PascalCase"]
              },
              {
                "selector": {
                  "kind": "variable"
                },
                "match": ".{2,}",
                "formats": ["camelCase"]
              },
              {
                "selector": {
                  "kind": "any"
                },
                "match": ".{2,}",
                "formats": ["camelCase", "CONSTANT_CASE", "PascalCase", "snake_case"]
              }
            ]
          }

And here are my test files:

valid.ts

import React from 'react';

function track(data: { event: string; interaction_name: string }) {
  console.log(data);
}

// ------------------------------
// COMPARISON

// 1. Prefixed
type TFoo = {
  bar: string;
  baz: number;
};

// 2. Uppercased
type TUppercaseType = {
  foo: string;
};

// 3. Long enough
type TLongEnough = {
  foo: string;
};

// 4. Long enough
[1, 2, 3].map((num) => num + 1);

// 5. Using camelCase
const fooBar = 1;
let barBaz = 2;
barBaz = 3;

// ------------------------------
// FALSE POSITIVES CHECK

// 6. Any format allowed
track({
  event: 'foo',
  interaction_name: 'bar',
});

// 7. __html allowed
// biome-ignore lint/security/noDangerouslySetInnerHtml: Not what this test is about
<div dangerouslySetInnerHTML={{ __html: '<p>foo</p>' }} />;

// 8. <T> allowed
function doubleArray<T>(arr: T[]): T[] {
  return arr.concat(arr);
}

// 9. zod allowed
import z from 'zod';

// ------------------------------
// IGNORE

export default 69;

invalid.ts

// 1. Not prefixed
type Foo = {
  bar: string;
  baz: number;
};

// 2. Lowercased
type lowercaseType = {
  foo: string;
};

// 3. Too short
type T = {
  foo: string;
};

// 4. Too short
[1, 2, 3].map((n) => n + 1);

// 5. Not using camelCase
const foo_bar = 1;
let bar_baz = 2;
bar_baz = 3;

My config finds first 4 issues just fine, but:

• Fails on test 5
• Produces false positive on test 8 and 9

I have a suspicion that there is a way to make this infinitely easier, but I got completely lost. I can't seem to find a way to just tell Biome to check what my original intention is: types starting with T, no one-character variables, don't do ANYTHING else. I feel like the last selector does more harm than good, but without it, the situation is even worse. How do I proceed? TIA!

[Conaclos]

If you use match and formats, you have to capture a string in order to check against formats; otherwise formats is never used.
Also, if you don't specify formats and capture a string with match, the captured string is automatically forwarded to the next selection.

I could test the following config:

        "useNamingConvention": {
          "level": "error",
          "options": {
            "strictCase": false,
            "conventions": [
              {
                "selector": {
                  "kind": "typeAlias"
                },
                "match": "T(.{2,})",
                "formats": ["PascalCase"]
              },
              {
                "selector": {
                  "kind": "typeParameter"
                },
                "formats": ["PascalCase"]
              },
              {
                "selector": {
                  "kind": "objectLiteralMember"
                },
                // accept everything
                "match": ".*"
              },
              {
                "selector": {
                  "kind": "any"
                },
                "match": "[yz_]|(.{2,})"
               // Here I didn't specify `formats` in order to apply the following conventions, including the default ones.
              },
              {
                "selector": {
                  "kind": "variable"
                },
                "formats": ["camelCase"]
              }
            ]
          }

Let me know if you don't understand something.

[Conaclos]

@wojtekmaj Have you any suggestion to improve the rule's docs? What did confuse you in the docs?

[wojtekmaj]

Absolutely! Here are my thoughts, both regarding docs and rule design itself, which I think was the source of the confusion for me.

• Most important one: When providing my own conventions, I did not expect the default ones to still be running. This makes the rule particularly hard to configure, as I had to add a ton of overrides. Without this I could slash my config in half. While I achieved my goal, the amount of code to do so is crazy when compared with @typescript-eslint/naming-convention equivalent.
  • I would prefer having them documented. This would make it easier to write overrides for them.
• Lack of minLength, maxLength, prefix, suffix forces users to work with match, which isn't the most elegant thing to work with, and doesn't clarify intentions of linter config author well enough.
  • Because of this, even the simplest goals, like forbidding one-letter variables globally, may be hard to achieve. A set of "recipes" would be really nice!
• I had trouble configuring formats for function arguments: function foo({ some_param }) {} - is it a function parameter? Is it an object property? A (destructured on-the-fly) variable, perhaps? Not sure.
• One-word, all uppercase variable names are caught by PascalCase even with strictCase = false. In our codebase, this caused TSEO to error out, but TSEOImage to pass. I get it, I truly do, but it was upsetting I had to rename these types to make them pass.

[Conaclos]

I did not expect the default ones to still be running

Do you mean you expected that all kind of identifiers be enabled by default if a user specifies some conventions?

Without this I could slash my config in half.

If you want to accept any identifiers for the rest of declarations, you can simply end with the following convention:

{
  "selector": { "kind": "any" },
  "match": ".*"
}

you can even on;it of the selector because it is any:

{
  "match": ".*"
}

At me, it is looks pretty straightforward to remove any default conventions?

I would prefer having them documented. This would make it easier to write overrides for them.

Yeah, we could add more example. Thanks for the suggestions.

Lack of minLength, maxLength, prefix, suffix forces users to work with match, which isn't the most elegant thing to work with, and doesn't clarify intentions of linter config author well enough.

I get your point. My intention was to provide a general way of expressing it because I think that's really specific usages. I don't want the complexity of adding many properties for niche usages.

I had trouble configuring formats for function arguments: function foo({ some_param }) {}

Yeah, we are missing docs for that. Destructured variable are ignored because you are constrained by the property names of the object.

all uppercase variable names are caught by PascalCase even with strictCase = false. In our codebase

That's actually a good point. It looks like fair to recognize uppercase variables like non-strict PascalCase.

[Conaclos]

I opened #3277 to address some documentation concerns reported by @wojtekmaj
@wojtekmaj, If you have some time feel free to review the PR.

[wojtekmaj]

Well I didn't have free time, but you save me a couple of minutes every single day, so I cannot imagine not giving at least some back :)