Apr 13, 2024 · 11 comments · 14 replies
{{actor}} deleted this content .
-
OverviewWe're working towards a new v8 major versions for typescript-eslint. Major versions are when we have an opportunity to adjust the shared configs. Exciting!
As with 6.0 (#6014), this is a proposal for the new shared configs. We're looking for feedback from the community before we go ahead and make the changes.
Please, let us know here or in the typescript-eslint Discord's #v8 channel: what feedback to you have? 💜
Hint: search for 🆕 to find newly added rules, and ➕ or ➖ to see config changes.
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
-
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
0 replies
-
If no-useless-template-literal is destined to be renamed, should we sneak that in before it gets added to recommended to minimize impact of the renaming (on things like disable comments etc)?
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
1 reply
-
Agreed, added to the v8 milestone. Good call!
Beta Was this translation helpful? Give feedback.
{{actor}} deleted this content .
-
Interesting note: prefer-find and prefer-includes at first seem like rules that would be in stylistic*. prefer-includes is currently in strict*. I don't mind keeping them in strict because they do help code be a little more performant... but I suspect the main benefits for users are stylistic. It'd be very rare for actual perf benefits to come out of them. So I'm leaning towards moving them to stylistic*. Does anybody have thoughts on this?
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
3 replies
-
The way I see it, both those rules satisfy the conditions when flagging that "there is a unique and uncontroversially better way to write this, though there is not a significant correctness concern with the existing code". So there's no reason ever to not want them, but they're not terribly important to use either. As a user my intuition would that that should be part of strict, whereas stylistic would have to do more with opinionated things that don't have a uniquely better way to write them; one is just picked largely for the sake of consistency (consistent-type-assertions springs to mind as a good example of this). Idk if that's really the intention of those configs or not, though.
Beta Was this translation helpful? Give feedback.
-
I think it would be good to also consider that strict is recommended only for proficient typescript developers. And I think these rules are easy to use and easy to adopt. So they could go for stylistics in that sense.
I think prefer-find could go to even recommended. I don't see it being really opinionated. Instead it will catch old code that could be updated. There is probably only handful of cases where you would not want to use that rule.
We recommend a TypeScript project extend from plugin:@typescript-eslint/strict only if a nontrivial percentage of its developers are highly proficient in TypeScript.
Beta Was this translation helpful? Give feedback.
{{actor}} deleted this content .
-
I'm leaning towards stylistic for now, as (a) they really do mostly give objectively better stylistic benefits and (b) per @rubiesonthesky's note, strict locks them behind "you should be proficient" notes.
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
2 replies
-
consistent-type-imports might too opinionated for us to turn on, I think.
Mainly because it has a fixer and it fixes to an opinionated default.
stylistic is our opinionated default but I am weary of complaints.
We could document that people should use import/consistent-type-specifier-style if they want to customise the style...
🤔
Beta Was this translation helpful? Give feedback.
-
no-import-type-side-effects isn't really useful for people unless they are using verbatimModuleSyntax as well. With that turned off the "empty imports" are all properly elided by everything.
It's a useful rule if you have to use verbatimModuleSyntax - otherwise it's just noise and not necessary.
Beta Was this translation helpful? Give feedback.
-
Just heads up, ➕ and ➖ emojis are not visible on dark mode.
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
4 replies
-
Oh, blurgh. Good callout. Now we have to figure out - what's a good replacement pair of emojis... 🤔
Beta Was this translation helpful? Give feedback.
-
remove: 🗑️ (or ❌ but that is too red IMO.)
add: 🎉 / ✨
(I honestly do not know, I think it could be just + and - :)
Beta Was this translation helpful? Give feedback.
-
Mmhh it'd be nice to have two emojis with meanings related to each other... surprisingly hard to find. I'm surprised there aren't + and - versions in squares the way there are 🔼 / 🔽 .
Beta Was this translation helpful? Give feedback.
-
👍 / 👎 :D There is ✅ and ❎ but I think those are hard for some people as they use same color and the different symbol is just so small.
I think the table could use ✨ for meaning "new". Both meaning as a new rule and as a new item in shared config. Because I had difficulties remembering what every emoji means :D But I'll leave this to you (or others) to find best option.
(Found this kind of tool where you could check in both modes easily https://github-emoji-picker.rickstaa.dev/ but emojis are pretty limited in this way)
Beta Was this translation helpful? Give feedback.
-
prefer-namespace-keyword
module will be probably marked as deprecated soon in typescript microsoft/TypeScript#57913
I wonder would it be helpful for ts-eslint users that this rule would be moved to recommended so they would get heads up beforehand? Of course, marking it as deprecated does not mean that it will stop working. :)
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
1 reply
-
I like it! It straddles the line between "recommended" and "stylistic"... but given the strong TypeScript push, that's enough for me to be happy switching it over.
Beta Was this translation helpful? Give feedback.
-
Update (May 11th): with #8977's no-empty-object-type merged into v8, updating the table to include that being added to recommended.
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
1 reply
-
Note that once #9102 is merged, we'll have some more changes to the table.
Beta Was this translation helpful? Give feedback.
-
I'm excited to see all this work on v8! Is there a rough timeline for when this version will drop? I think I'm right in saying ESLint v9 has been out nearly a couple of months now but the current version of typescript-eslint doesn't support it, preventing new users/projects from using the latest major version.
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
1 reply
-
No strict timeline. When we get to things, really.
You can use the canary releases if you need v9 support now.
As volunteer maintainers we work on things when we have the bandwidth -- and unfortunately we haven't had the bandwidth. ESLint sadly did not coordinate with us and released before we were ready and at a time where we have been time poor.
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
0 replies
-
Calling out that return-await is on track to be added to the strict config, a la #8667/#9604
Beta Was this translation helpful? Give feedback.
You must be logged in to vote
0 replies
{{actor}} deleted this content .
-
I'm coming from blog post https://typescript-eslint.io/blog/announcing-typescript-eslint-v8 to see what where the actual changes to some rules. :)
Some updates that could be made to table or just noting these here for next user that is curious why they are listed removed in config diffs. Though if you read the blog lost further, you also get the same explanation :D
ban-types was deprecatedno-loss-of-precision was deprecatedno-var-requires was deprecatedBeta Was this translation helpful? Give feedback.
You must be logged in to vote
1 reply
-
Aha thank you, great callout! Updating now.
Beta Was this translation helpful? Give feedback.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emojiYou can’t perform that action at this time.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4