Replies: 3 comments 3 replies
-
True - technically, all sorts of seemingly safe changes can cause changes to code. Reordering imports can cause changes when modules have side effects upon import; reordering object property destructures can cause changes when properties have getters that cause side effects. But the vast, vast majority of uses for the In other words: there can be stylistic or even logical reasons why a formatting concern is valid, but the rule really does enforce the formatting concern.
Have you tried it? It does flag this case: https://typescript-eslint.io/play/#ts=5.0.1-rc&sourceType=module&code=MYewdgzgLgBCBGArGBeGBvAvgKABQDMBXMYKAS3BlwEoMZNqbsg&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQHYHsBaWXRADwAdEBjAF0QBNCBbBWgS3ndPSkWmj5okcGAC+IMUA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA
This sentence caused some ... feelings in me. I will have to take some time to fully process them. 🙈 |
Beta Was this translation helpful? Give feedback.
-
Sorry, what I meant to write was this:
So I assume there are some Typescript-specific features that ESLint doesn’t know anything about and so And also it was my understanding that the primary reason for a semicolon rule is not formatting but preventing programming pitfalls. At least that’s how I read the rational on the eslint/semi rule. Import ordering on the other hand – while it can have an effect on the code – is in my understanding mainly done to have a tidier file and to find lines more quickly. So the intent concerns purely formatting reasons |
Beta Was this translation helpful? Give feedback.
-
Thanks for the clarification on the Still the categorization into formatting/stylistic/logical linters is hard for me to understand.
The second definition mentions semicolons but in the same sentence says it’s about rules that don’t impact runtime behavior. In fact, the runtime impact is presented as the distinguishing feature compared to stylistic rules. If you compare with this rule, it seems to have less impact on the runtime than the semi-rule, yet it is not a formatting rule: In summary, I think |
Beta Was this translation helpful? Give feedback.
-
RFC
The semi rule page has this big red banner:
On the linked page formatting rules are described as follows:
However, as far as I understand, semicolons don't fall into this category since absence of a semicolon can change the behaviour of your code. Example:
I know that there is an eslint rule
no-unexpected-multiline
. But I am not sure if this also works for Typescript reliably. After all,typescript-eslinttypescript-eslint/semi
was introduced specifically to make the semicolon rule work for Typescript.As long as this isn't settled, I thing it's incorrect to call
semi
a formatting rule.Additional Info
Any additional info...
Before you submit your RFC, please confirm the following. If any of these required steps are not taken, we may not be able to review your RFC. Help us to help you!
Beta Was this translation helpful? Give feedback.
All reactions