📎 Improve useNamingConvention options

[anonrig]

Description

It would be nice to support all cases of @typescript-eslint/naming-convention rule, such as the following usage:

    '@typescript-eslint/naming-convention': [
      'error',
      {
        selector: 'typeLike',
        format: ['PascalCase'],
        leadingUnderscore: 'allow',
      },
      {
        selector: 'enumMember',
        format: ['UPPER_CASE'],
      },
    ],

[Conaclos]

Note that we already have an option for enum member case. I am open to relax some default and adding some options. Could you be more explicit about the need?

[Conaclos]

@anonrig The rule already enforces PascalCase for every type-like entity and allow leading underscore. Have you a need to enforce other cases for type-like entities?

[Conaclos]

We are using rust for backend and all the fields are in snake_case. We want to have functions in camelCase but variables, fields in type and interface in snake_case

@nouman2075 I understand your use case. That's really specific. Let me think about that. By the way, why do you need variables in snake_case?

[nouman2075]

We want to enforce rule that variables, fields in type and interface should follow same casing. If we stick to camelCase then if we try to pass snake_case fields received from backend to other components, biome will throw error. Also the code will be bad if we use camelCase and snake_case together. So we should stick to one casing.

Just like Biome provide option for enum member, it should provide separate option for variables, functions, typeLike...
Here's the list of possible cases for naming convection in eslint

[Conaclos]

Thanks for these details. I will propose a change to support your use cases.

[ValentinGurkov]

Mocking also seems a bit difficult since if I attempt to mock an exported class in PascalCase, it forces me to use camelCase:

But then it won't match the export.

[Conaclos]

Proposal v1

I have spent some time thinking about your needs and more generally the needs of the community.

I propose to add a way to select a given set of names to apply a custom format and require a prefix/suffix. Unlike the ESLint rule, we provide a limited set of selectors.

Some selectors override others. For example, topLevelConst overrides const; const overrides variables. If a property is not set, the selector inherits from the property of the overridden selector.

type Case =  "camelCase" |  "PascalCase" | "CONSTANT_CASE" | "snake_case" 

type NamingConventionOptions = {
  strictCase?: boolean, // same option as now
  selectors: {
    [selector: Selector]?: {
      format?: Case[],
      prefix?: string[],
      suffix?: string[],
      exceptions?: string[],
    },
  },
  requireAscii: boolean,
  ignoreQuoted: boolean,
  /** @Deprecated */ enumMemberCase: Case,
}

type Selector  =
  | "default"
  | "typeLike" // class, interface, type alias, type parameter, enum
  | "interface"
  | "function" // function declaration, function expression
  | "namespaceLike" // namespace, import namespace, export namespace
  | "enumMember"
  | "method"
  | "property" // class prop, prop parameter, type prop, object prop
  | "privateProperty" // property with `private` or `protected` accessibility modifier
  | "objectProperty"
  | "staticProperty"
  | "staticReadonlyProperty"
  | "parameter"
  | "variable"
  | "const"
  | "topLevelConst"

Some examples of selectors:

• Require a leading underscore for private and protected properties

  {
    privateProperty: { prefix: ["_"] }
  }

• Allow a leading underscore for private and protected properties

  {
    privateProperty: { prefix: ["_", ""] } // order is important
  }

• Allow snake_case for types

  {
    typeLike: { format: ["PascalCase", "snake_case"] } // order is important
  }

• Require interface with a I prefix, except for MyException

  {
    interface: { prefix: ["I"], exceptions: ["MyException"] } // order is important
  }

With these new options, we could forbid leading and trailing underscores by default. The only exceptions are unused variables, which can always start with a single underscore.

We still accept a leading and trailing dollar sign. This can be overridden in the `default' selector.

[PointSingularity]

This looks awesome!
If this was implemented, it would allow me to finally fully migrate my work's legacy ESLint config:

  '@typescript-eslint/naming-convention': [
      'error',
      {
        selector: 'interface',
        format: ['PascalCase'],
        leadingUnderscore: 'forbid',
      },
      {
        selector: 'variable',
        format: ['camelCase', 'UPPER_CASE', 'snake_case'],
        leadingUnderscore: 'allow',
        custom: {
          regex: '^(any|Number|number|String|string|Boolean|boolean|Undefined|undefined)$',
          match: false,
        },
      },
    ],

[rujorgensen]

This proposal looks very interesting to me as well. I'm looking into potentially switching from eslint to Biome at work because of the excellent performance and helpful error descriptions. We have conventions for type/enum/interface -names where we sometimes prefix with "T", "E", or "I", and suffix with "_S". Can this be tracked somewhere?

[Conaclos]

Here #1900

[hilja]

Would it make sense to hard-code some exceptions for selected industry standards like S3? Or does it go against the Biome’s philosophy?

For some reason the S3 SDK does this:

S3.PutObject({
  Bucket: S3_IMAGES_BUCKET,
  Key,
  Body,
  ContentEncoding: 'base64',
  ContentType: img.mime,
  CacheControl: 'public, max-age=31536000', // year
})

[Conaclos]

But you aren't accepting. The above code will produce a lint error.

Maybe my explanation is confusing: What I mean is allowing by default camelcase, snake_case and PascalCase for literal object properties. For now, we only accept camelcase.

[Conaclos]

Will Biome have the concept of environments? One option could be to offer an S3 or whatever env for popular quirky packages.

It is not decided yet. However, I don't think so. Have you some references/docs about S3 conventions.

[hilja]

allowing by default camelcase, snake_case and PascalCase for literal object properties

Ah, that makes sense :)

Here's the input docs for PutObject, all properties are capitalized for some reason, and some use uppercase acronyms SSEKMSEncryptionContext etc.

[hilja]

if we should not accept snake_case and PascalCase by default for literal object properties.

This is actually a great idea, now that I've been aware of this more there are a lot of APIs that use snake_case or PascalCase. For example the Stripe API and most Postgres related things, because in pg case sensitive strings needs to be quoted: SELECT * FROM "MyPosts" so it's just easier to use snake_case.

[arendjr]

I'm not sure how I would feel about making the default more lenient for specific APIs. Personally, I would prefer to keep usage of such APIs constrained to specific modules/services, so I would configure overrides that allow specific patterns in those files or folders. I wouldn't like it if those patterns were allowed throughout a codebase though.

[Conaclos]

I've just published #2770 that adds options to useNamingConvention. Any opinions/reviews is welcomed :)