search

google / quiver-dart

A set of utility libraries for Dart
https://pub.dev/packages/quiver
Apache License 2.0
1.02k stars 133 forks source link

FakeAsync now has its own package #169

Closed seaneagan closed 10 years ago

seaneagan commented 10 years ago

I decided to go ahead and release FakeAsync as its own package:

http://pub.dartlang.org/packages/fake_async

Reasons:

I'm perfectly fine if you want to leave it in quiver, or I'd be happy to create a pull request to remove it and make any existing uses within quiver point to package:fake_async as well, just let me know.

@justinfagnani @yjbanov thanks for the initial code review on it, it helped a lot!

yjbanov commented 10 years ago

I think we should improve discoverability not by breaking into packages, but by giving Quiver's test utilities more visibility. I have two possibilities in mind:

  1. mention it above the fold in the docs
  2. create a single package quiver-testing for all testing utilities
    • smaller dependency

I disagree. Your code depends on libraries, not packages. A package is a unit of download, which does not matter much. You can, for example, have a package that depends on both "dart:html" and "dart:io" as long as the two dependencies do not show up in the same library.

Also breaking it up too much will lead to larger "pubspec.yaml" files for users and more version management. I think hunting for individual test utilities would be a pain for users.

Depends on what side of the release process you are. Releasing fake_async to pub is easy. Maintaining pubspec.yaml files and pulling into private repositories is harder since there are more packages to manage.

justinfagnani commented 10 years ago

I agree. I think if we split quiver up it'll be to still fairly-coarse grained packages, like quiver_testing. I'm torn between liking small packages and thinking that they get lost in the noise and don't attract enough attention on their own.

We certainly can and should release a lot more often, if that's a big reason why you want separate packages.

seaneagan commented 10 years ago

With smaller packages, you may need to add more dependencies to your pubspec.yaml, but you shouldn't need to rev the version constraints of those dependencies nearly as frequently, so IMO smaller packages actually lead to less pubspec.yaml maintenance.

Imagine I pull in quiver as a dependency just to use FakeAsync. Quiver then needs to make a breaking change to something completely unrelated, like quiver.iterables, so quiver releases version 0.27.0. I want to keep with the latest quiver for many reasons, including to stay compatible with any transitive dependency constraint I have on quiver, which has been or will soon be upgraded. I need to check the CHANGELOG, test with the new version, and release a new version of my package. Then the next week, quiver releases 0.28.0, again not releated to FakeAsync, and I have to go through the whole process again. Any maybe quiver's FakeAsync never sees any breaking changes, but I need to go through this any time quiver releases a new potentially breaking version.