Gathering detailed insights and metrics for eslint-plugin-i18next-no-undefined-translation-keys
Gathering detailed insights and metrics for eslint-plugin-i18next-no-undefined-translation-keys
Installations
npm install eslint-plugin-i18next-no-undefined-translation-keysReleases
Unable to fetch releases
Developer
kevindice
Developer Guide
BETA
Module System
CommonJS
Min. Node Version
12.x || 14.x || >= 16
Typescript Support
No
Node Version
18.19.0
NPM Version
10.2.3
Statistics
1 Stars
29 Commits
1 Forks
1 Watching
1 Branches
3 Contributors
Updated on 24 Jul 2024
Languages
JavaScript (100%)
Total Downloads
Cumulative downloads
Total Downloads
608,165
Last day
-29.8%
1,525
Compared to previous day
Last week
-5.1%
8,486
Compared to previous week
Last month
79.5%
30,602
Compared to previous month
Last year
24%
261,913
Compared to previous year
Daily Downloads
Weekly Downloads
Monthly Downloads
Yearly Downloads
Dependencies
1
Peer Dependencies
1
Dev Dependencies
4
Versions
eslint-plugin-i18next-no-undefined-translation-keys
Why?
A few years ago, I was working on a very large React Native project with a couple hundred engineers. In the early phase of the project, there wasn't formal governance around modularity and code-sharing - these things tend to evolve organically at first. As adjacent teams started to see value in sharing certain things with each other, it became common to move significant chunks of code into a shared module. Unfortunately, it was also common for translations to silently break in the process. Each team had their one 1 or 2 lerna modules, each with their own i18next namespace. As code got moved, there was no automated check in place that the new namespace in which it rendered had all the same keys defined.
Even today, the i18next project docs recommend a Typescript-based approach. This is fraught with caveats - you have to use TS 5, you have to enable strict mode, if your project has multiple i18next instances, then you probably can't use type-safe translations.
Frankly, the TS-based approach does not solve the problem very well. And, for those who need it most - people on big sprawling projects with multiple i18next instances - it doesn't solve the problem at all.
Instead, I went with an eslint-based approach.
What?
This plugin gives you two rules:
translation-key-string-literal- Asserts that translation keys should be string literals only - otherwise, we can't statically analyze themno-undefined-translation-keys- Detects translation keys in your code which are missing from translation files
These are intended to be used in conjunction with:
i18n-json/valid-json(who doesn't love well-formed JSON?)i18n-json/identical-keys(ensures that amongst all of your languages, the exact same set of keys is defined)i18n-json/sorted-keys(optional, but it is nice to have your keys alphabetized)
Operational Note:
Since we know that translations for other languages aren't immediately available, the recommendation here is to put empty strings in place where you are still waiting for a translation. Then, on whatever cadence makes sense, you can run a recursive check on each file to source the empty strings and batch those together for the translators to work on.
Installation
You'll first need to install ESLint:
1npm i eslint --save-dev
Next, install eslint-plugin-i18next-no-undefined-translation-keys:
1npm install eslint-plugin-i18next-no-undefined-translation-keys --save-dev
Usage
Add i18next-no-undefined-translation-keys to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:
1{ 2 "plugins": [ 3 "i18next-no-undefined-translation-keys" 4 ] 5}
Then configure the rules you want to use under the rules section.
1{ 2 "rules": { 3 "i18next-no-undefined-translation-keys/translation-key-string-literal": "error", 4 "i18next-no-undefined-translation-keys/no-undefined-translation-keys": [ 5 "error", 6 { 7 "namespaceTranslationMappingFile": "namespaceMapping.json", 8 "defaultNamespace": "default" 9 } 10 ] 11 } 12}
And your namespaceMapping.json file should map your namespaces to translation file paths like so:
1{ 2 "shared": "packages/shared/lang/en.json", 3 "unitsOfMeasure": "packages/shared/lang/uom-en.json", 4 "user": "packages/user/lang/en.json" 5}
For those who don't use i18next namespaces (most people), you can skip defining defaultNamespace, and your namespaceMapping.json file can be as simple as this:
1{ 2 "default": "libs/path/to/your/english.json" 3}
Note: The no-undefined-translation-keys rule will ignore any non-string-literal calls to t().
Supported Rules
i18next-no-undefined-translation-keys/translation-key-string-literali18next-no-undefined-translation-keys/no-undefined-translation-keys
No vulnerabilities found.
No security vulnerabilities found.