Lint: depend_on_referenced_packages for docImports

[jonasfj]

Using:

/// @docImport 'package:test/test.dart';
library;

This works fine, but if package:test isn't a direct-dependency, or if it's a dev_dependency you probably shouldn't do this in lib/.

When rendering documentation on pub.dev we don't resolve dev_dependency, the same is the case when your documentation is rendered in a hover in the IDE.

I can also see the argument that we shouldn't care about this, because functionally it doesn't matter if you do this. Though, it'll cause problems when we analyze your package for scoring, and render your documentation on pub.dev

[bwilkerson]

@srawlins Does the analyzer currently make a distinction between direct non-dev dependencies and other dependencies when resolving comment references?

The lint would be reasonable (either enhancing the existing lint or adding a new one), but I'm more concerned about having consistent semantics across the tools.

[srawlins]

When rendering documentation on pub.dev we don't resolve dev_dependency, the same is the case when your documentation is rendered in a hover in the IDE.

Very interesting! I think users should not add dependencies and tie up version constraints etc just so that doc-imports can be resolved. Maybe if the version constraint is any?

@srawlins Does the analyzer currently make a distinction between direct non-dev dependencies and other dependencies when resolving comment references?

No.

[FMorschel]

That would require a way to identify the generated files (drift, for example can generate .drift.dart) and I'd still prefer a way to define basically all warnings without having to manually write them all again or remember to copy/paste.

But yes, that would definitely be better than the current solution to add file regexp to analyzer -> exclude that stops small renaming and similar actions.

[srawlins]

@FMorschel did you comment on the wrong issue?

[FMorschel]

Oops, sorry, yes. I had this and #60798 open. Thanks for noting!