New Rule: keys-patterns

[dananaprey]

Rule details

Allows to set a keys patters to specific JSON files

What type of rule is this?

Suggests an alternate way of doing something

Example code

Real life example:

I have a JSON files for application localization

{
  "firstLocalizationKey_i18n": "Some translation 1",
  "secondLocalizationKey_i18n": "Some translation 2",
  "thirdLocalizationKey_i18n": "Some translation 3",
  ...
}

I want to prohibit adding keys to it that do not match a certain pattern (for this example /(^[a-zA-Z]+_i18n$)/)

I propose to add rule which add an ability to set patters to specific JSON files

Rule example:

{
  "keys-patterns": [
    "error",
    {
      "/(^[a-zA-Z]+_i18n$)/": ["./src/i18n/en.json", "./src/i18n/it.json"],
      "/(^[a-zA-Z]$)/": ["./src/some.json"],
    }
  ]
}

Different patterns can be assigned to different files. If you do not specify anything for file, there will be no pattern

Participation

• I am willing to submit a pull request to implement this rule.

Additional comments

In my example, there is a JSON file without nesting. If we have nesting maybe this rule will not be necessary, a schema is already needed there, but we can discuss it here

[nzakas]

Thanks for the suggestion. I understand what you're trying to do, but I'm not sure it's universal enough to include in this plugin. (Keep in mind, you can always just write the rule yourself -- it doesn't need to be in this plugin for it to exist.)

{
  "keys-patterns": [
    "error",
    {
      "/(^[a-zA-Z]+_i18n$)/": ["./src/i18n/en.json", "./src/i18n/it.json"],
      "/(^[a-zA-Z]$)/": ["./src/some.json"],
    }
  ]
}

I'm not sure what this is supposed to do. If you want different settings for different files, the canonical ESLint way of doing it would be:

export default [
  {
    files: ["./src/i18n/en.json", "./src/i18n/it.json"],
    rules: {
      "keys-patterns": [ "error", "/(^[a-zA-Z]+_i18n$)/"]
    }
  },
  {
    files: ["./src/some.json"],
    rules: {
      "keys-patterns": [ "error", "/(^[a-zA-Z]$)/"],
    }
  },
];

@eslint/eslint-team thoughts?

[JoshuaKGoldberg]

As with #54, agreed that this seems specific to one library's use cases. -1 from me on the specific rule.

On the other hand, I think there could be utility in adding an equivalent to no-restricted-syntax for JSON. Please forgive my forgetting/lacking familiarity with the new ESLint languages, is that something that can be done now?

• If no-restricted-syntax already works with JSON, maybe this is more a docs issue on explaining how to use it?
• If not, could it be?

[mdjermanovic]

I agree this doesn't seem universal to include in this plugin.

• If no-restricted-syntax already works with JSON, maybe this is more a docs issue on explaining how to use it?

Yes, the core no-restricted-syntax rule can be used with any language. I think we can make it official by updating the docs for this rule. @nzakas what do you think?

This config should work for the example from the original post:

import json from "@eslint/json";

export default [
    {
        files: ["**/*.json"],
        plugins: {
            json
        },
        language: "json/json"
    },
    {
        files: ["src/i18n/en.json", "src/i18n/it.json"],
        rules: {
            "no-restricted-syntax": [
                "error",
                {
                    selector: "Member > String[value!=/^[a-zA-Z]+_i18n$/].name",
                    message: "Object keys should match /^[a-zA-Z]+_i18n$/"
                }
            ]
        }
    },
    {
        files: ["src/some.json"],
        rules: {
            "no-restricted-syntax": [
                "error",
                {
                    selector: "Member > String[value!=/^[a-zA-Z]$/].name",
                    message: "Object keys should match /^[a-zA-Z]$/"
                }
            ]
        }
    }
];

[dananaprey]

Thanks, I'll try to use the no-restricted-syntax rule to achieve my goal!

[nzakas]

Yes, the core no-restricted-syntax rule can be used with any language. I think we can make it official by updating the docs for this rule. @nzakas what do you think?

Yes, we can do that. At some point, we probably want to split it out of the core into its own plugin, though, to avoid this ambiguity.