-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
feat(eslint-plugin): [no-restricted-imports] support import = require #7709
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
feat(eslint-plugin): [no-restricted-imports] support import = require #7709
Conversation
Thanks for the PR, @Josh-Cena! 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 site configuration. |
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.
Swell, LGTM!
I think this is a breaking change and blocked on going into our next major release?
@@ -6,7 +6,7 @@ description: 'Disallow specified modules when loaded by `import`.' | |||
> | |||
> See **https://typescript-eslint.io/rules/no-restricted-imports** for documentation. | |||
|
|||
This rule extends the base [`eslint/no-restricted-imports`](https://eslint.org/docs/rules/no-restricted-imports) rule. | |||
This rule extends the base [`eslint/no-restricted-imports`](https://eslint.org/docs/rules/no-restricted-imports) rule. It adds support for the type import (`import type X from "..."`, `import { type X } from "..."`) and `import x = require("...")` syntaxes. |
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.
[Praise] Yes! I've started souring on extension docs that don't explicitly say what gets added.
specifier.importKind === 'type', | ||
)) | ||
!isAllowedTypeImportPath(importSource) && | ||
!isAllowedTypeImportPattern(importSource) |
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.
[Cleanup] Nit: there's a teeny bit of duplication with calling !isAllowedTypeImportPath(importSource) && !isAllowedTypeImportPattern(importSource)
. Maybe worth a helper function? It's only two places, so maybe not...
I don't think this qualifies as a breaking change (if people really think so it can be behind an option). We usually don't automatically categorize "more errors" as breaking change, especially in the case where an error should be highly expected and the lack of one can only be explained as a bug/oversight. |
Yeah I think you're right. In theory, if a lot of devs still used 🚀 ship it! |
PR Checklist
import = require()
syntax. #2563Overview