Skip to content
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

Lint for package dependency should/shouldn't be a dev dependency #57176

Open
kevmoo opened this issue Feb 14, 2015 · 2 comments
Open

Lint for package dependency should/shouldn't be a dev dependency #57176

kevmoo opened this issue Feb 14, 2015 · 2 comments
Labels
analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. linter-lint-request P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug

Comments

@kevmoo
Copy link
Member

kevmoo commented Feb 14, 2015

If a dependency is used in bin/lib it MUST be a non-dev dependency
If a dependency is not used in bin/lib it SHOULD be a dev dependency

@pq pq added the type-enhancement A request for a change that isn't a bug label Feb 15, 2015
@zoechi
Copy link
Contributor

zoechi commented Feb 6, 2016

AFAIR @NweiZ has a different opinion on dependencies used for example in bin.
There was a long discussion on a pub issue. I hope I didn't mix anything up - it's a while back.

@jonasfj
Copy link
Member

jonasfj commented Feb 24, 2021

Warning against importing dev_dependencies from lib/ or bin/ is easy and huge win.

But a lint which suggests that a package could be in dev_dependencies will likely have many false positives, like:

  • asset/resource packages (like icons, js libraries, images, fonts, etc),
  • constraints on transitive dependencies (used to restrict a transitive dependency),
  • packages called as subprocesses or launched in an isolate.

There are legitimate reasons for a package to be a direct-dependency without being imported.


Furthermore, it's generally rather harmless to drag along an unnecessary dependency, that should have been in dev_dependencies. It increases the risk of dependency conflicts, but beyond that it's reasonably harmless.
Unless, you've accidentally added a package like test, build_runner or a code-gen tool as direct-dependency, but:

  • There are very few packages like test and build_runner,
  • They are generally only intended to be used as dev_dependencies,

Hence, a better solution might be to add a bit in the pubspec.yaml for test and build_runner which indicate that these packages are intended to be used as dev_dependencies. That way:

  • The linter simply needs to warn when such package is added in dependencies as oppose to dev_dependencies, and,
  • Tools like dart pub add <package> could be tweaked to add such packages under dev_dependencies by default without requiring the --dev flag.

I'm not sure how a pubspec.yaml indicates that it's intended to be used as a dev_dependency, but a simple boolean might do?
Or maybe you just annotate all public symbols with @visibleForTesting 🤣

@srawlins srawlins added the P3 A lower priority bug or feature request label Oct 11, 2022
@devoncarew devoncarew added analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. labels Nov 18, 2024
@devoncarew devoncarew transferred this issue from dart-lang/linter Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
analyzer-linter Issues with the analyzer's support for the linter package area-analyzer Use area-analyzer for Dart analyzer issues, including the analysis server and code completion. linter-lint-request P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants