This module provides the functionality to automatically check
Resources for potential errors and other insights.
Use cases could be:
- check if all
Messageswere translated to another language
- check if the name of a brand always uses the same naming schema e.g.
- check if the tone of a message does not sound aggressive
- check if the translated message does not exceed a certain length
- ... and probably a ton of other use cases. Please tell us if we should add one to this list.
Note: In the future we will provide a
CLIto make it easier to use this package.
inlang.config.js file supports a
lint property you can use to configure the linting process.
lint property expects an
rules. Rules can be configured by passing parameters to the function call.
- the first parameter is the lint level. Currently supported levels are
- the second parameter is a custom configuration for the given rule. Some rules may be configured and some rules might not support this.
There exist some lint rules you can use to check your
Resources against. You can find them here. Or you can write your own rules.
Creating your own lint rule
You can use the provided
createLintRule function to create a lint rule. By using the provided function, you will get back a strongly typed rule.
createLintRule expects 2 parameters.
The id of the rule.
The naming convention for the id is:
camelCaseand it must be split by a
.character to prevent naming collisions e.g.
A callback function that gets passed the settings of the lint rule. It must return an object with the following properties:
visitors: An object that contains functions that will be called during the linting process.
The linting process will visit each node recursively and then calls the corresponding
visitorsfunction if specified. The
visitorobject expects the following properties:
Resource(optional): the visitor functions that will be called when a Resource node gets processed.
Message(optional): the visitor functions that will be called when a Message node gets processed.
Pattern(optional): the visitor functions that will be called when a Pattern node gets processed.
'skip'to skip the processing of all child nodes.
Be aware that
undefinedif the corresponding node does not exist on the target or reference resource.
All defined functions can be synchronous or asynchronous. The lint process traverses all nodes in sequence and awaits each step individually. Keep that in mind. It could affect the performance if you call a lot of long-running functions.
Manual processing of nodes
If you wish to manually traverse all nodes e.g. to make some requests in parallel, you can do that with this approach:
Be aware that you are responsible to check if your code reaches all nodes.
A lint rule can expect a
settings object. To specify what type of settings the lint rule expects, you can pass it as a generic argument to the
The settings will be passed by a user to configure the behavior of the lint rule.
The lint module is small on purpose to not expose features that might not be used by users but need to be maintained for backwards compatibility. We will implement features as requested by users.
It is expected that most improvements can be exposed via (the object) arguments.
Use the object argument pattern to API changes
To ease the iterative improvement approach, most public APIs use the object argument pattern.
Users must explicitly provide provide the lint level.
Letting rules define the default lint level in
createLintRule leads to complex types, more conditional logic, and the benefit to developers is unclear. I vote to remove the "feature" due to:
- Users face a hidden lint level that might make them wonder why certain things are errors or warnings.
- Rule writers need to think about "should my rule be an error or a warning"?