"depend_on_referenced_packages" and "dev_dependencies"

[RohitSaily]

Dart SDK version: 3.8.0-24.0.dev (dev) (Wed Jan 22 12:05:43 2025 -0800) on "macos_x64"

Problem

The linter rule depend_on_referenced_packages requires that referenced packages are listed under dependencies of the user package's pubspec.yaml. Understandably, by default it is does not count a package as referenced if it is listed under dev_dependencies because that dependency will not be accessible at runtime.

I have a development dependency that I use throughout my code that simply provides annotations for development-time that are not necessary at runtime. If I want to use the linter rule to enforce explicit dependencies, I have to silence the check for this rule at every import of that dependency. I would like to not have to do that all the time; the development dependency is used by every file.

Proposed Solution

Provide a way to explicitly list select development dependencies as being depended on in analysis_options.yaml so this linter rule can be suppressed for those specific dependencies.

[lrhn]

The current rule is easy: if a file under lib/ depends on the package, it must be a dependency. If any other file depends on it, it must be at least a dev-dependency.

You have a situation where you add dependencies to files in lib/ that you intended to remove before publishing. You're only using it during development, so philosophically speaking it's a development dependency.

I suggest you just make it a normal dependency, and remove it form the dependencies when you remove it from the files in lib/, rather than complicating the logic for an otherwise simple rule.

Or use // ignore: comments on the imports. Also makes them easier to find when you need to remove them.

[RohitSaily]

In my case, I use annotations from development dependencies and don't remove them, as they aren't involved at runtime. The same goes for the import statements.

I agree that allowing customization here would add unnecessary complexity, especially since it's not clear to me that this would be widely used. I guess I'll just live with the ignore comments or set up my own version of the linter rule for personal use, since a customized version of the rule seems simple enough to implement.

[lrhn]

In my case, I use annotations from development dependencies and don't remove them, as they aren't involved at runtime.

That's not a stable approach unless you're developing a stand-alone application. In that case, you can, and should, just make it a normal dependency.

If any other package depends on your package, then its transitive dependencies will not include your package's dev-dependencies,
which means that unless some other package in the dependency graphs has a non-dev-dependency on the annotation package, the imports (and therefore annotations) left in the lib/ code will cause compile-time errors.

[RohitSaily]

That makes sense, I did just test what you said out to better my understanding and can confirm it is exactly as you have said. I had assumed/required the end-user of any package that uses the development package to also have that same development package as a development dependency.

Theoretically, in terms of how packages are managed, built, and/or executed would there be any technical difference (negligible or not) in always having a package as a development dependency?

[lrhn]

Having all the dev-dependencies of all your own dependencies (normal and dev) including in your own dev-dependencies has a much higher risk of a resolution conflict.

Currently, the only dev-dependencies that a Pub package depends on are its own. That's the entire point of having dev-dependencies, as dependencies that the package does not force on other packages.
It's packages that you, the package author, needs for something (like tests or tools), but that package clients, those who only use the files in the lib/ directory, do not need.

That means that you can be as specific as you want to. You can have a dev-dependency on an exact version, like test: 1.17.4.
You can have dev-dependencies that are github dependencies or local dependencies on other packages in the same mono-repo.
It doesn't affect anyone else, it's entirely your problem and your responsibility.

If it affected client packages too, then it would just be a dependency, there would be no difference between dev-dependencies and just dependencies. I guess the dev-dependencies could potentially be omitted from the program when building the final product, but not if anyone imports them into lib, even if just to use them as annotations.

[RohitSaily]

Thanks for the explanations! It makes a lot of sense to me now. I am closing this issue since the rule works as intended