Lint

This module provides the functionality to automatically check Resources for potential errors and other insights.

Use cases could be:

• check if all Messages were translated to another language
• check if the name of a brand always uses the same naming schema e.g. MyApp instead of my-app or myApp
• 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.

Usage

Note: In the future we will provide a CLI to make it easier to use this package.

Configuration

The inlang.config.js file supports a lint property you can use to configure the linting process.

The lint property expects an Array of rules. Rules can be configured by passing parameters to the function call.

• the first parameter is the lint level. Currently supported levels are 'error' and 'warn'
• the second parameter is a custom configuration for the given rule. Some rules may be configured and some rules might not support this.

inlang.config.js

Lint Rules

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.

Example:

The createLintRule expects 2 parameters.

1. The id of the rule.
   
   The naming convention for the id is: camelCase and it must be split by a . character to prevent naming collisions e.g. myService.checkGrammar.

2. 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 visitors function if specified. The visitor object 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 target or reference could be undefined if 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.

Settings

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 createLintRule function.

The settings will be passed by a user to configure the behavior of the lint rule.

inlang.config.js

Design decisions

Iterative improvements.

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"?

Flow of the lint module