Add ability to ignore certain keys in no-unused-keys rule

[wolfgangwalther]

What rule do you want to change?

no-unused-keys

Does this change cause the rule to produce more or fewer warnings?

Fewer.

How will the change be implemented? (New option, new default behavior, etc.)?

New option.

Please provide some example code that this change will affect:

{
  "@intlify/vue-i18n/no-unused-keys": [
    "error",
    {
      ignore: ['ignore_me']
    }
  ]
}

<i18n lang="yaml" locale="en">
ignore_me: "I am used, but you wouldn't know!"
hello world: Hello World!
</i18n>

<template>
  <div>{{ $t('hello world') }}</div>
</template>

What does the rule currently do for this code?

Report unused 'ignore_me' key.

What will the rule do after it's changed?

Report all good.

Additional context

Would be good if it was possible to add either plain values or regex to the ignore array, to be flexible.

Most flexible would be to pass a function to ignore that is called to check whether the key should be ignored or not.

[ota-meshi]

Thank you for posting this issue.

However, I don't understand your use case.
Why do you want to ignore unused keys?
I think it should be removed or used as it is not actually used. If not, I think you need to turn off the rule.

[wolfgangwalther]

I have some keys that appear to be unused to the rule, but are in fact used:

• One case are dynamically used keys, e.g. to translate error messages based on an error number received from the server, or different text based on a prop of that component etc.
• Another case is a mixin that I use in a lot of components, that uses the same two keys to translate custom messages for each component it is used in.

I tried a few variations of disabling comments and only managed to disable the whole <i18n> block, but not individual keys:

<!-- eslint-disable @intlify/vue-i18n/no-unused-keys this works, but only for the following block -->
<i18n lang="yaml" locale="en">
header breadcrumb: Home
header title: Home
</i18n>

<!-- the following block still throws errors, the comment above needs to be repeated here -->
<i18n lang="yaml" locale="de">
# eslint-disable-next-line @intlify/vue-i18n/no-unused-keys this does not work
header breadcrumb: Home
header title: Home
</i18n>

Maybe the issue is with yaml comments not being parsed, I don't know. But right now I would have to create each i18n block twice: once for keys that appear unused and once for keys that should be checked regularly be the rule.

Also, since I use this mixin a lot across the codebase, this would lead to a loot of disable comments - where a simple ignore option would work the same.

[ota-meshi]

Thank you for your explanation.

I have more questions.

One case are dynamically used keys, e.g. to translate error messages based on an error number received from the server, or different text based on a prop of that component etc.
Another case is a mixin that I use in a lot of components, that uses the same two keys to translate custom messages for each component it is used in.

I don't think it's worth using the no-unused-keys rule because these cases have a lot of false positives.
What is the worth to you to use the no-unused-keys rule with the addition of options? I'm worried that it's probably hard to list the names to add to ignore.

[wolfgangwalther]

The no-unused-keys rule is very valuable to me. Right now, I have to periodically enable the rule, go through the big list of errors manually and filter out the false alarms. Whenever I do that, I notice some real errors, that I fix - it would be really helpful, if I could use the no-unused-keys rule by default and in CI, too.

Providing a regex (if the whole key was available as string) or function callback in the ignore option would be flexible enough to easily add everything I need. The keys to ignore follow a common pattern.

However, better support for disable comments in YAML would help already, too. But I fear that this might be harder to do?

[ota-meshi]

Thank you for your explanation. I think regex support is probably a must.

or function callback

Unfortunately, the ESLint configuration file does not allow to specify a function.

However, better support for disable comments in YAML

It's hard to implement now, as you say, but I may implement it in the future 😅.

[tmerten]

hi @wolfgangwalther and @ota-meshi . I was wondering about the same thing and you started this just a week ago :).

Let me start with a simple workaround, which might work for others as well: Introduce another translation file (.json in our case) file and add this to .eslintignore. Put your dynamic keys (or in our case often keys coming from the backend) there to prevent them from being linted.

[tmerten]

And here is a different idea to approach this architecture wise:

There might be a LOT of dynamic keys in different places around the code and at the same time the .eslint config is often not maintained by the folks coding. That said defining such exceptions in the config or the translation file might become unmaintainable pretty soon (e.g. dynamic keys are deleted from the source but not the config).

I'd propose to put some kind of annotation in the code that the linter can find and expand. E.g.

(always hard to find good names ;) )
<!-- eslint @intlify/vue-i18n/no-unused-keys markAsUsed: "^locations\..*" -->
<!-- eslint @intlify/vue-i18n/no-unused-keys doNotCheck: "^locations\..*" -->
<!-- eslint @intlify/vue-i18n/no-unused-keys disableFor "^locations\..*" -->
<!-- eslint @intlify/vue-i18n/no-unused-keys dynamicKeyDefinition "^locations\..*" -->

<li v-for="location in locations" :key="location.id">{{ $t(`locations.${location.countryCode}`) }}</li>

I do not think eslint disable can take arguments and maybe there is no need to have an "official" eslint annotation at all. It could be some @intlify/vue-i18n internal convenvtion, too (?). I don't know much about eslint's internals myself, sorry.

Anyways, the ideas is that this might be easier to code (linter) and maintain (users of the linter) as there is a higher chance that devs notice that the dynamic key annotation is somewhat related to the code around without having to check .eslint files.

[wolfgangwalther]

Works perfectly, thank you very much! :)