In the current state, we have defined a detailed list of rules to check migration conditions using our custom ESLint plugin. Below is the complete list according to the documentation:
- `@exadel/esl/deprecated-4-alert-action-params` - Rule for deprecated `AlertActionParams` alias for `ESLAlertActionParams`.
- `@exadel/esl/deprecated-4-generate-uid` - Rule for deprecated `generateUId` alias for `randUID`.
- `@exadel/esl/deprecated-4-deep-compare` - Rule for deprecated `deepCompare` alias for `isEqual`.
- `@exadel/esl/deprecated-4-event-utils` - Rule for deprecated `EventUtils` alias for `ESLEventUtils`.
- `@exadel/esl/deprecated-4-panel-action-params` - Rule for deprecated `PanelActionParams` alias for `ESLPanelActionParams`.
- `@exadel/esl/deprecated-4-popup-action-params` - Rule for deprecated `PopupActionParams` alias for `ESLPopupActionParams`.
- `@exadel/esl/deprecated-4-traversing-query` - Rule for deprecated `TraversingQuery` alias for `ESLTraversingQuery`.
- `@exadel/esl/deprecated-4-toggleable-action-params` - Rule for deprecated `ToggleableActionParams` alias for `ESLToggleableActionParams`.
- `@exadel/esl/deprecated-4-tooltip-action-params` - Rule for deprecated `TooltipActionParams` alias for `ESLTooltipActionParams`.
- `@exadel/esl/deprecated-4-media-rule-list-parse` - Rule for deprecated `ESLMediaRuleList.parse` alias for `ESLMediaRuleList.parseQuery` or `ESLMediaRuleList.parseTuple`.
- `@exadel/esl/deprecated-4-base-decorators-path` - Rule for deprecated `@attr`, `@prop`, `@boolAttr`, `@jsonAttr`, `@listen` import paths.
- `@exadel/esl/deprecated-5-alert-action-params` - Rule for deprecated `AlertActionParams` alias for `ESLAlertActionParams`.
- `@exadel/esl/deprecated-5-panel-action-params` - Rule for deprecated `PanelActionParams` alias for `ESLPanelActionParams`.
- `@exadel/esl/deprecated-5-popup-action-params` - Rule for deprecated `PopupActionParams` alias for `ESLPopupActionParams`.
- `@exadel/esl/deprecated-5-tooltip-action-params` - Rule for deprecated `TooltipActionParams` alias for `ESLTooltipActionParams`.
However, in reality, consumers are unlikely to care about this complexity. The plugin version is typically in sync with the library, and we have utilities to check the versions of both the plugin and the library. As library maintainers, we cannot physically or logically undo some of the breaking changes that the plugin is designed to detect. Therefore, there is no practical reason for consumers to disable individual rules.
Moreover, at this point, handling a large batch of rules is slow (performance is not optimal for the recommended list).
It is proposed to replace the migration rules with a single, optimized rule for each major version.
Acceptance Criteria
Minimal Valuable Changes
All mentioned rules should be reduced to version-specific changes.
The final set of rules should be limited to:
@exadel/esl/deprecaton-4
@exadel/esl/deprecaton-5
Error messages should be clear and describe the actual case. It is proposed to move the full description to the rule definition (ideally, with the deprecation version). The plugin documentation should not go into detail about migration or deprecation decisions, only declaring the rule list, while the rule output should be as more informative as posible.
Tech Notes
We likely no longer require a complex defaults builder.
We will continue to support non-flat ESLint configurations.
Tests should still be included, and the rule configuration spec (containing the deprecation data and changes) should be separated from the rule implementation.
The implementation can be split into parts if necessary.
In the current state, we have defined a detailed list of rules to check migration conditions using our custom ESLint plugin. Below is the complete list according to the documentation:
However, in reality, consumers are unlikely to care about this complexity. The plugin version is typically in sync with the library, and we have utilities to check the versions of both the plugin and the library. As library maintainers, we cannot physically or logically undo some of the breaking changes that the plugin is designed to detect. Therefore, there is no practical reason for consumers to disable individual rules.
Moreover, at this point, handling a large batch of rules is slow (performance is not optimal for the recommended list).
It is proposed to replace the migration rules with a single, optimized rule for each major version.
Acceptance Criteria
Minimal Valuable Changes
All mentioned rules should be reduced to version-specific changes.
The final set of rules should be limited to:
@exadel/esl/deprecaton-4
@exadel/esl/deprecaton-5
Error messages should be clear and describe the actual case. It is proposed to move the full description to the rule definition (ideally, with the deprecation version). The plugin documentation should not go into detail about migration or deprecation decisions, only declaring the rule list, while the rule output should be as more informative as posible.
Tech Notes
eslint-plugin