-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
fix(typescript-eslint): export plugin
, parser
, and configs
that are compatible with both defineConfig()
and tseslint.config()
#11475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Thanks for the PR, @kirkwaiblinger! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
View your CI Pipeline Execution ↗ for commit 6dd9d70
☁️ Nx Cloud last updated this comment at |
Shouldn't this also be updated? typescript-eslint/docs/getting-started/Quickstart.mdx Lines 54 to 63 in b2ee794
Along with the example on that same page to start using |
Possibly could... Though in the name of caution it might be worth releasing the types change and waiting a week to make sure it's doesn't end up messing up people's configs too before we take down the notice. Could go either way.
This will for sure not happen as part of this PR, but endorsing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is test-d.ts
run by vitest? TIL
If another way of configuring the project is supported, shouldn't the overall readme have a way to do this? I mean, if you want people to start using it, it would be nice to know how it works... |
See #10935 |
PR Checklist
defineConfig()
types #10899Overview
Third time's the charm 🙃
I realized that, if we're extremely vague about what the parser, plugin, and configs are, we can easily satisfy both the expected types from
defineConfig()
andtseslint.config()
, without running into the many incompatibilities I experienced during previous attempts. While this sacrifices precision, the exact shapes of those objects aren't actually important at all to users; it's only important that they be usable within their configs. So, I think this is a worthwhile tradeoff.It's possible that some plugin authors, or downstream consumers that use our tools in some way other than in their lint configuration might experience some type errors as a result of this. Fixing these errors should be quite simple, since one can use type assertions to get the previous (also quite vague) types: