Extending I18next-CLI Linting: Tags And Attributes

Dec 5, 2025 by Alex Johnson 51 views

Extending i18next-CLI Linting: Easily Build Upon Recommended Values for Tags and Attributes

When working with i18next and the i18next-CLI, you might find yourself in a situation where you want to extend the default linting rules for accepted tags and attributes rather than completely replacing them. This article delves into a feature proposal that addresses this need, offering solutions and workarounds for a smoother development experience. We'll explore the motivations behind this proposal and potential approaches to achieve it.

The Challenge: Overriding Default Linting Rules

When configuring the i18next-CLI for linting, you often need to specify which HTML tags and attributes are considered valid within your translation files. For instance, if you're using web components, you might add a configuration like this:

lint: {
 acceptedTags: ['some-web-tagname']
}

However, the problem arises when this configuration overrides the default list of accepted tags. This means you lose the standard HTML tags that i18next-CLI typically recognizes, forcing you to redefine the entire list. This can be cumbersome and inefficient, especially when you only want to add a few custom tags or attributes.

Why is this important? Because maintaining a complete list of accepted tags and attributes manually is time-consuming and error-prone. You might miss some standard tags, leading to false positives during linting. The goal is to extend the existing list effortlessly, ensuring that both default and custom tags are recognized.

To effectively address this, we need a mechanism that allows us to build upon the recommended values without sacrificing the default configurations. This ensures a more streamlined and maintainable approach to linting in i18next-CLI.

Motivation: Extending Instead of Replacing

The primary motivation behind this feature proposal is to enable developers to extend the lint.acceptedTags and lint.acceptedAttributes configurations, rather than replacing them entirely. This approach offers several benefits:

Reduced Configuration Overhead: Instead of copying and pasting the entire default list of tags and attributes, you only need to specify the additional ones required for your project.
Maintainability: When i18next-CLI updates its default list, your configuration automatically benefits from these updates without requiring manual intervention.
Consistency: By building upon the defaults, you ensure that your project adheres to a consistent set of linting rules, reducing the risk of overlooking standard HTML tags or attributes.

Imagine this scenario: You are working on a large project with numerous custom web components. Each component introduces new tags and attributes that need to be recognized by the linter. Without the ability to extend the default list, you would have to manually maintain a comprehensive list of all standard HTML tags plus your custom tags. This is not only tedious but also increases the likelihood of errors.

Furthermore, consider the scenario where the i18next-CLI team updates the default list to include new HTML5 tags or attributes. If you are overriding the default list, you would need to manually merge these updates into your configuration. This adds unnecessary overhead and complexity to your workflow.

Therefore, the ability to extend the lint.acceptedTags and lint.acceptedAttributes configurations is crucial for efficient and maintainable i18next-CLI linting.

Proposed Solutions: Merging and Exporting Defaults

Several approaches can be taken to address the challenge of extending the lint.acceptedTags and lint.acceptedAttributes configurations. Here are a couple of potential solutions:

1. Merge Option

One approach is to introduce a mergeAcceptedTags (or attributes) boolean value, similar to the existing extract.mergeNamespaces option. This option would allow you to specify whether the provided acceptedTags and acceptedAttributes should be merged with the default lists.

lint: {
 acceptedTags: ['some-web-tagname'],
 mergeAcceptedTags: true
}

In this scenario, setting mergeAcceptedTags to true would ensure that some-web-tagname is added to the default list of accepted tags, rather than replacing it. This provides a simple and intuitive way to extend the linting rules without overriding the defaults.

2. Exporting Default Configuration

Another approach is to export a default configuration that users can pick and choose properties from. This would allow developers to access the default lists of accepted tags and attributes and selectively add them to their own configurations.

// Accessing the default configuration
import { defaultConfig } from 'i18next-cli';

lint: {
 acceptedTags: [...defaultConfig.lint.acceptedTags, 'some-web-tagname']
}

By exporting the default configuration, developers have the flexibility to customize their linting rules while still leveraging the default values provided by i18next-CLI. This approach offers more control and transparency, allowing developers to see exactly which tags and attributes are being included in their configuration.

Considerations

When implementing either of these solutions, it's important to consider the following:

Performance: Ensure that merging or accessing the default configuration does not introduce significant performance overhead.
Configuration Complexity: Strive for a solution that is easy to understand and configure, minimizing the learning curve for new users.
Backward Compatibility: Ensure that any changes do not break existing configurations or introduce unexpected behavior.

By carefully considering these factors, we can implement a solution that effectively addresses the challenge of extending the lint.acceptedTags and lint.acceptedAttributes configurations in i18next-CLI.

Practical Examples and Use Cases

To further illustrate the benefits of extending the linting configurations, let's explore some practical examples and use cases.

Example 1: Web Components Project

Consider a project that heavily relies on web components. These components often introduce custom tags and attributes that are not recognized by default by the i18next-CLI linter. Without the ability to extend the default list, developers would need to manually maintain a comprehensive list of all standard HTML tags plus the custom web component tags.

With the proposed solution, developers can simply add the custom web component tags to their configuration while still benefiting from the default list of accepted tags.

lint: {
 acceptedTags: ['my-custom-component', 'another-custom-element'],
 mergeAcceptedTags: true
}

This ensures that the linter recognizes both standard HTML tags and the custom web component tags, reducing the risk of false positives and improving the overall linting experience.

Example 2: Using ARIA Attributes

Another common use case is when working with ARIA attributes for accessibility. ARIA attributes provide semantic meaning to HTML elements, making web applications more accessible to users with disabilities. However, these attributes may not always be included in the default list of accepted attributes.

By extending the acceptedAttributes configuration, developers can ensure that ARIA attributes are properly recognized by the linter.

lint: {
 acceptedAttributes: ['aria-label', 'aria-describedby'],
 mergeAcceptedAttributes: true
}

This helps to promote accessibility best practices and ensures that the web application is compliant with accessibility standards.

Example 3: Custom Data Attributes

Developers often use custom data attributes to store application-specific data directly within HTML elements. These attributes are prefixed with data- and can be used to store any type of data.

To ensure that these custom data attributes are recognized by the linter, developers can extend the acceptedAttributes configuration.

lint: {
 acceptedAttributes: ['data-custom-id', 'data-product-name'],
 mergeAcceptedAttributes: true
}

This allows developers to use custom data attributes without triggering false positives during linting.

Conclusion

In conclusion, the ability to extend the lint.acceptedTags and lint.acceptedAttributes configurations in i18next-CLI is a valuable feature that can greatly improve the development experience. By providing a way to build upon the default linting rules, developers can reduce configuration overhead, improve maintainability, and ensure consistency across their projects.

The proposed solutions, such as the mergeAcceptedTags option and exporting the default configuration, offer practical and intuitive ways to achieve this goal. By carefully considering the implementation details and potential challenges, we can create a solution that effectively addresses the needs of i18next-CLI users.

By adopting these approaches, developers can streamline their workflow, reduce the risk of errors, and ensure that their projects adhere to best practices for internationalization and localization. If you're interested in learning more about i18next, consider visiting the official i18next documentation.