Don't export matcher

[seaneagan]

I noticed a 1.0.0 milestone was created for this repo. Due to the export of matcher, once that's released, any breaking changes to matcher will also require a breaking change (and thus major version bump) to this package.

Also, exporting matcher highly constrains the versions of matcher that can be used by a package dependening on this package (i.e. almost all packages). But matcher is useful in many contexts outside of unit testing. For example, I'd like to use it in unscripted via the constrain package which already does use Matcher. It is merely a means to test conditions and provide human readable lanuage for them, and explainations of why particular values don't match.

Adding dependencies on both packages wouldn't be too burdensome, especially if you use something like den (e.g. den install test matcher) or if your editor supports something similar. Making the versions match up will be easy once matcher stabilizes, which could be expedited via #2326.

I don't see having to import test and matcher (or matchers) as a big deal, especially since you're often just copying over boilerplate code from another test file, and also the boilerplate could be generated for you via dart-archive/matcher#52.

[seaneagan]

Ideally there would be a deprecation period. Is it possible to mark an export as deprecated?

@deprecated
export package:matcher/matcher.dart;

[seaneagan]

Filed a bug for deprecated exports.

[nex3]

To be clear, although we don't have a problem with people using matcher for other things, its intended use-case is for unit testing. If a situation comes up where we have to decide between supporting matcher as a generic declarative-predicate library and making it more usable for testing, we'll choose the latter.

While it's true that the export creates a tight constraint on matcher relative to unittest, this doesn't mean there's a tight constraint in a more general sense. To the extent that unittest can vary—which should be a pretty wide extent, especially after 1.0.0 when there will be no more breaking changes for a long time—matcher can vary as well. It's no tighter than if unittest itself contained all the matchers.

Essentially every test that's written using unittest needs to use matchers. It's the only way of making assertions that produce helpful error messages that exists in the ecosystem right now, so re-exporting saves a line of boilerplate from every test anyone writes in Dart. That's a lot of net usability, and as I mentioned before, test usability trumps declarative-predicate usability.