search

dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.27k stars 1.58k forks source link

Lint for unspecified version constraints on packages #57177

Open kevmoo opened 9 years ago

pq commented 9 years ago

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 commented 9 years ago

@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

seaneagan commented 9 years ago

@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.

munificent commented 9 years ago

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.

nex3 commented 9 years ago

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.