proposal: dev_only_dependency

jakemac53 commented 1 year ago

DO put development dependencies in dev_dependencies

Description

If a package specifies that it is a development only dependency, then you should only include it in the dev_dependencies section of your pubspec.yaml, and not the regular dependencies section.

The one exception to this rule is if your package is also listed as a development only dependency.

Details

Some packages, like lints, test, and build_runner should only be depended on as dev_dependencies by most users. Adding them to the regular dependencies section is not only unnecessary but creates real issues around version lock in the ecosystem, as those dependencies release breaking versions.

As an example, no two packages should fail to version solve together just because they are on a different major version of the lints package - those lints only apply for local development of the package.

New pubspec opt in

This would require the ability to specify a package as "development only". We can bikeshed on what that should be called, but it should probably just be a new top level field in the package, something like:

name: my_package
dev_only: true
...

Kind

This guards the ecosystem against version lock and bloated downloads for packages.

Bad Examples

name: my_package
dependencies:
  # These should be `dev_dependencies`.
  lints: <version>
  test: <version>

Good Examples

name: my_package
dev_dependencies:
  lints: <version>
  test: <version>

name: flutter_test
dev_only: true
dependencies:
  # Allowed because flutter_test it itself a dev_only dependency
  test: <version>

Discussion

cc @sigurdm @jonasfj for thoughts on adding something to the pubspec. This may not have to be something official either.

Discussion checklist

[ ] List any existing rules this proposal modifies, complements, overlaps or conflicts with.
[ ] List any relevant issues (reported here, the SDK Tracker, or elsewhere).
[x] If there's any prior art (e.g., in other linters), please add references here.
[ ] If this proposal corresponds to Effective Dart or Flutter Style Guide advice, please call it out. (If there isn't any corresponding advice, should there be?)
[ ] If this proposal is motivated by real-world examples, please provide as many details as you can. Demonstrating potential impact is especially valuable.

jakemac53 commented 1 year ago

One similar piece of prior art is the test_only attribute for build rules in bazel. This prevents non-test code from depending on test_only dependencies, so test code does not leak into applications.

sigurdm commented 1 year ago

I think we want an attribute in pubspec.yaml with the intended use (globally activated tool, dev dependency,...) you should probably be allowed to be in more than one category...

dart pub add could also use this to default the section it adds a dependency to.

CC: @jonasfj

jakemac53 commented 1 year ago

Yes that sounds like it would fit, this could essentially be a list of "tags"? We could either restrict those tags to the ones known by pub (at least with a warning) or we could leave it open ended so other tools could have their own tags they support.

We could possibly support searching by tag or surfacing the tags on pub.dev as well.

sigurdm commented 1 year ago

Yes that sounds like it would fit, this could essentially be a list of "tags"?

We are actively working on "topics" that is more free-form categories/tags you can add to the pubspec and browse on pub.dev.

I would prefer that for the feature discussed in this issue we have a predefined set of values with specific semantics, especially when we start basing hints and cli behavior on it.

jakemac53 commented 1 year ago

I would prefer that for the feature discussed in this issue we have a predefined set of values with specific semantics, especially when we start basing hints and cli behavior on it.

Ok, that makes sense if we have slightly different plans already in progress.

Should these values be negatable as well? In other words, should we let packages opt out of being "globally activate-able" etc?

sigurdm commented 1 year ago

Should these values be negatable as well? In other words, should we let packages opt out of being "globally activate-able" etc?

Good question - my intuition says no. Perhaps by including the list you by default negate anything not included.

But we don't have a fully specified proposal yet, just some ideas kicking around.

jonasfj commented 1 year ago

Perhaps we should write a proposal, this wouldn't be a huge feature after all

dart-lang / linter