[no-restricted-imports] add allow type import options

What rule do you want to change? Rule name: no-restricted-imports Add allowType in rule options.

https://github.com/typescript-eslint/typescript-eslint/issues/2661#issuecomment-706570884

Does this change cause the rule to produce more or fewer warnings? Fewer warnings when special case.

How will the change be implemented? (New option, new default behavior, etc.)? Check importKind property in ImportDeclaration.

Please provide some example code that this change will affect:

// wrong
import A from './a'

// correct
import type A from './a'

What does the rule currently do for this code? We need to limit only type import some packages sometimes. For example: When using package in user project runtimes, Like vetur, ts-loader.

What will the rule do after it’s changed? We make sure that only type import is used.

Are you willing to submit a pull request to implement this change? Yes

[nzakas]

Thanks @bradzacher 🙏 You’re doing a great job with the plugin.

[kaicataldo]

Currently, adding syntax to ESTree is the best way to get support in ESLint core.

I personally am always in favor of making @babel/eslint-parser and @typescript-eslint/parser more first class citizens - because so many people use these parsers - but at this point, we I don’t think we have the resources to do this. We’re struggling as it is to implement core changes, and new issues are constantly created for the existing core rules.

Core rules maintained by the ESLint team is currently a pain point that gets distributed to every level of the ESLint community:

1. They take up a lot of the resources of the core team to maintain, making it much more difficult for us to improve core itself.
2. Because we don’t have the resources to support other common flavors of JS in core rules, it ends up being a huge pain point for parser/plugin maintainers (thinking particularly of Babel and TypeScript), as they have to reimplement core rules and figure out ways to work around the current API which really treats them as second class citizens.
3. The Babel/TypeScript communities have to deal with more complicated configuration/missing rule features that users of “standard” JS get.
4. This translates into more issues/maintenance burden for ESLint core and plugin/parser maintainers, and the cycle repeats.

Given these constraints, I think the ideal outcome would be for the community to eventually take on maintenance of core rules (as a plugin in a separate org), freeing us up to reallocate those resources to core itself. If we ever hit that point, I’d really love to explore how to make Babel and TypeScript have first class support in core, or at least create an API that makes it easier for custom parsers to integrate with rules.

Sorry, this ended up being more of a brain dump of what I’ve been following for a long time now. Any ideas of how we could improve things would be really appreciated ❤️