[New rule] avoid-restricted-imports

[roman-petrov]

Please describe what the rule should do:

I propose a rule similar to ESLint no-restricted-imports. There might be many use cases for it. In our project (a design system component library) we need to restrict import from Flutter material.dart because we do not use Material Design and must not depend on it anywhere.

Without configuration this rule should simply do nothing. I think we need to have a flexible configuration here, the most important for me is to configure rule per file glob pattern.

In nearest future I would like to discuss this rule and also I plan to provide a PR.

If your rule is inspired by other please provide link to it:

no-restricted-imports.

What category of rule is this? (place an "X" next to just one item)

[ ] Warns about a potential error (problem) [x] Suggests an alternate way of doing something (suggestion) [ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about (it will be better if you can provide both good and bad examples):

Just possible rule configuration:

- avoid_restricted_imports
   - paths: ["some/**/folder/*.dart", "another/folder/**.dart"]
     deny: ["package:flutter/material.dart"]
     message: "Do not import Flutter Material Design library, we should not depend on it!"
   - paths: ["core/*.dart"]
     deny: ["package:flutter_bloc/flutter_bloc.dart"]
     message: "State management should be not used inside "core" folder."

BAD

import "package:flutter/material.dart";
import "package:flutter_bloc/flutter_bloc.dart";

GOOD

No restricted imports in listed folders.

Are you willing to submit a pull request to implement this rule? Yes, in a few weeks.

[incendial]

@roman-petrov can you please use existing template for new rules proposal (with code examples)?

[roman-petrov]

@incendial , it is hard to describe this new rule in terms of "bad" / "good" code since the most complex part for it is its configuration. However, I tried to update rule proposal using "new rule" template, please take a look.

In 2-3 weeks I plan to provide a PR for it so some feedback from you and maybe other community people would be great.

[incendial]

it is hard to describe this new rule in terms of "bad" / "good" code since the most complex part for it is its configuration. However, I tried to update rule proposal using "new rule" template, please take a look.

I think you did great, thank you! As for feedback, the rule looks solid and definitely useful

[incendial]

Actually, one thing bothers me: what do you think about changing the name a bit? From avoid-restricted to avoid-banned?

[roman-petrov]

I just borrowed the word "restricted" from ESLint rule :) So "banned" might be better, not sure, I am not an expert in English. So, in short, I don't mind:)

[incendial]

I'm not an expert either 😄 , but we already have ban-name, which should be renamed to avoid-banned-names in the next major and it'd be consistent to have avoid-banned-imports and avoid-banned-names`, wdyt?

[roman-petrov]

I like consistency, so - yes, in terms of consistency the word "banned" sounds better.

[fzyzcjy]

Any plans to implement this? If not I may work on it :)

@roman-petrov @incendial

[fzyzcjy]

WIP now: https://github.com/dart-code-checker/dart-code-metrics/pull/868

[fzyzcjy]

Ready for review now #868

[roman-petrov]

Any plans to implement this? If not I may work on it :)

@roman-petrov @incendial

Definitely not plan now, you PR seems doing exactly what we need, thank you! 😉 Today I will try to participate in review if you don't mind.

[incendial]

Oh, sorry for the delay, looking into the PR 👀

[incendial]

Available in 4.16.0! 🚀