support nested packages in firehose

[jakemac53]

Fixes https://github.com/dart-lang/ecosystem/issues/276

Adds support for published packages nested under unpublished packages. In particular, this adds support for workspace packages to firehose.

~I need to add a test still, will do that before landing. The easiest way would be to migrate to using workspaces in this package, otherwise I will need to create test fixtures to mimic a workspace repo. @devoncarew any opposition to migrating this repo to use workspaces, or would you prefer an explicit test for that setup? The current test just uses the current repo as a test fixture.~ tests added

[github-actions[bot]]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:firehose	0.9.1	ready to publish	firehose-v0.9.1
package:dart_flutter_team_lints	3.1.0	already published at pub.dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[github-actions[bot]]

PR Health

Breaking changes :heavy_check_mark:

Details

| Package | Change | Current Version | New Version | Needed Version | Looking good? | | :--- | :--- | ---: | ---: | ---: | ---: | |firehose|None|0.9.0|0.9.1|0.9.0|:heavy_check_mark:|

Changelog Entry :heavy_check_mark:

Details

| Package | Changed Files | | :--- | :--- | Changes to files need to be [accounted for](https://github.com/dart-lang/ecosystem/wiki/Changelog) in their respective changelogs.

Coverage :heavy_check_mark:

Details

| File | Coverage | | :--- | :--- | |pkgs/firehose/lib/src/repo.dart| :green_heart: 93 % | This check for [test coverage](https://github.com/dart-lang/ecosystem/wiki/Test-Coverage) is informational (issues shown here will not fail the PR).

API leaks :heavy_check_mark:

Details

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API. | Package | Leaked API symbols | | :--- | :--- |

License Headers :heavy_check_mark:

Details

``` // Copyright (c) 2024, the Dart project authors. Please see the AUTHORS file // for details. All rights reserved. Use of this source code is governed by a // BSD-style license that can be found in the LICENSE file. ``` | Files | | :--- | | _no missing headers_ | All source files should start with a [license header](https://github.com/dart-lang/ecosystem/wiki/License-Header).

Package publish validation :heavy_check_mark:

Details

| Package | Version | Status | | :--- | ---: | :--- | | package:firehose | 0.9.1 | **ready to publish** | | package:dart_flutter_team_lints | 3.1.0 | already published at pub.dev | Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[jakemac53]

I will go ahead and just add a test fixture for now, shouldn't be too bad

[jakemac53]

cc @sigurdm @jonasfj as well just for FYI, not sure if firehouse was on your radar

[jakemac53]

My understanding is that the workspace feature was designed to support a single solve amongst all workspace packages. That would make sense for some mono-repos but not others (for instance, not this repo, which is a more heterogeneous mix of packages).

Fwiw, while I agree it might not be an intuitive fit, the workflow overall fits really any mono_repo quite well and provides development improvements regardless:

• Only need to do a single pub get for the whole repo, easier to get started and also for maintenance.
• Fewer analysis contexts means less memory, and more efficient analyzer in general.
• Better support for includes in shared analysis_options.yaml files. You don't need to remember to add the dep into every single package.

If you can't share a version solve for some reason (which should be rare), you can easily opt out individual packages from the workspace.

The downsides I am aware of are:

• Implicit path dependency on all workspace packages may not be what you want.
• Have to upgrade dependencies across the entire repo at once (although, you can work around this by temporarily opting out packages from the workspace).

But, just a thought :). In general, I do find the workflow to be a lot nicer personally.