linter icon indicating copy to clipboard operation
linter copied to clipboard

Lint for unspecified version constraints on packages

Open kevmoo opened this issue 10 years ago • 5 comments

kevmoo avatar Feb 14 '15 20:02 kevmoo

Awesome. I've been thinking about pub lints. Glad to have the ball rolling.

Could you fill in some more details? Are there any exceptions?

How strong should this advice be? I'm guessing DO rather than PREFER? In that case, how about:

DO specify version constraints for all package dependencies.

Is there further validation we can do on constraints?

FWIW: here are some rough docs on writing lints. Any additional bits (good/bad examples, etc), greatly appreciated!

pq avatar Feb 15 '15 02:02 pq

@kevmoo : Also, is none the same as any?

In particular, I notice the advice for application packages is to specify any for their deps:

https://www.dartlang.org/tools/pub/glossary.html#application-package

pq avatar Feb 15 '15 17:02 pq

@munificent @nex3 I know you were considering adding more package validation features such as this to pub itself at some point. Wanted to loop you in case you have an opinion on this. I think most of the pub lints would not really be "style" issues, more along the lines of of not following best practices or going against pub conventions.

seaneagan avatar Feb 16 '15 14:02 seaneagan

Natalie and I don't currently have any plans to add linting to pub itself. It would be nice, but it's really unlikely we'll find the time to do it this century. I'd be happy if the linter did this.

munificent avatar Feb 17 '15 17:02 munificent

Well, we do have a system in place to do some validation of packages before they get uploaded, which actually includes this specific issue. I've always wanted to expand that to some degree, but never really had time, and now that we're getting a dedicated linter it may be less necessary. Generally the checks we have are focused on maintaining the integrity of the package ecosystem, since it's possible for one busted package to cause rippling problems.

This particular validation is risky to do without more context, for what it's worth. "Application" packages, which is to say packages that are intended to be run on their own and not used as libraries, are actually encouraged to avoid constraints for their dependencies. The expectation is that everyone working on them will want to have an identical set of dependency versions, so we encourage users to check in their lockfiles and use pub upgrade to handle their dependency versioning.

nex3 avatar Feb 17 '15 20:02 nex3