You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 25, 2019. It is now read-only.
By ading console.log to rules with the same name from different configurations (tslint-microsoft-contrib and tslint-eslint-rules have some conflicting name), I found out that the order in extends matters for which rule is used: the first extends that defines a rule will be used.
(When the the script triggers loading of the rules, it loads all of the active rules from all configurations.)
Currently the report colloects all rules with the same name and link them together, so all information isa avalable, but the report doesn't know about the order in tslint.json yet, it only knows about tslint rules taking precedence over all other configurations.
By loading the configurations manually one by one (should be able to load them using node resolution, we do not need to load tsint:* presets since they always win), and detecting the order, the report should provide the correct rule information depending on the config.
The text was updated successfully, but these errors were encountered:
karfau
changed the title
warn about active rules with conflicting names
Properly detect winning rule when different sources provide same rule name
Mar 16, 2018
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
By ading console.log to rules with the same name from different configurations (
tslint-microsoft-contrib
andtslint-eslint-rules
have some conflicting name), I found out that the order inextends
matters for which rule is used: the first extends that defines a rule will be used.(When the the script triggers loading of the rules, it loads all of the active rules from all configurations.)
Currently the report colloects all rules with the same name and link them together, so all information isa avalable, but the report doesn't know about the order in
tslint.json
yet, it only knows about tslint rules taking precedence over all other configurations.By loading the configurations manually one by one (should be able to load them using node resolution, we do not need to load
tsint:*
presets since they always win), and detecting the order, the report should provide the correct rule information depending on the config.The text was updated successfully, but these errors were encountered: