Skip to content

Split the 65 tool wrappers into 14 Fallout.Application.Tools.<Family> projects#11

Open
ChrisonSimtian wants to merge 3 commits into
tooling/extract-abstractionsfrom
tools/split-application-tools
Open

Split the 65 tool wrappers into 14 Fallout.Application.Tools.<Family> projects#11
ChrisonSimtian wants to merge 3 commits into
tooling/extract-abstractionsfrom
tools/split-application-tools

Conversation

@ChrisonSimtian

@ChrisonSimtian ChrisonSimtian commented Jun 29, 2026

Copy link
Copy Markdown
Owner

Splits all 65 tool wrappers out of Fallout.Common into 14 per-family Fallout.Application.Tools.<Family> projects under src/Tools/ — the tools step of the onion migration (tools = Application layer).

Stacked on #10 (provides the Fallout.Application.Tooling.* contract leaves). Review order: #9#10 → this.

14 families

DotNet (11) · Testing (9) · Coverage (8) · Signing (6) · Packaging (6) · Notifications (5) · VersionControl (4) · Versioning (4) · Containers (4) · Cloud (3) · Shell (2) · JavaScript (1) · Gaming (1) · Documentation (1) — single-tool families are forward-looking categories (e.g. JavaScript→yarn/pnpm, Shell→bash, Documentation→Docusaurus).

How it was done (3 staged commits)

  1. Notifications — proven pattern on a clean leaf.
  2. 9 independent families — bulk move.
  3. 4 entangled families + cycle-break — DotNet/Coverage/Containers/VersionControl.

Cycle-break (Fallout.Common ↔ Tools)

  • GitHubTasks.cs split: pure GitRepository URL/identity helpers (+GitHubItemType) move down next to GitRepositoryFallout.Build/VCS/GitHubUrlExtensions.cs (namespace Fallout.Common.Git, no Octokit); the Octokit client stays in the GitHub tool. ChangeLogTasks now resolves them via Fallout.Common.Git — no tool dependency.
  • TeamCity.cs → DotCover: nameof → string literals (no tool ref).
  • 3 TeamCity DotNet/MSBuild bridge extensions → Tools.DotNet; LatestGitHubReleaseAttributeTools.VersionControl.
  • Cross-family Coverage→DotNet, Containers→DotNet are ProjectReferences.

Conventions

  • Non-breaking: tools keep their Fallout.Common.Tools.<Tool> namespace → consumers only gain ProjectReferences (Cli, Components, _build, tests).
  • Octokit/Azure.* package refs moved off Fallout.Common onto the owning families.
  • InternalsVisibleTo granted to families whose attributes use Common's (still-internal) value-injection plumbing — interim bridge.
  • Architecture suite governs all 14: each must not depend on Components/Cli. Tools reaching up into Fallout.Build (value-injection bases) is documented interim debt.

⚠️ Follow-up (tracked, deferred — out of scope here)

Align tool namespaces from Fallout.Common.Tools.* to Fallout.Application.Tools.<Family>.* (breaking; needs GenerateTools namespaceProvider change + consumer using updates), and make value-injection a public Application API to drop the IVT bridges.

Verification

  • Full fallout.slnx build (incl. dogfood build/): 0 errors.
  • Architecture suite: 31/31 green.

🤖 Generated with Claude Code

@ChrisonSimtian ChrisonSimtian added the target/2026 Releases on the 2026 calendar line label Jun 29, 2026
@ChrisonSimtian ChrisonSimtian marked this pull request as ready for review June 29, 2026 03:41
@ChrisonSimtian ChrisonSimtian changed the title Split tool wrappers into Fallout.Application.Tools.<Family> projects Split the 65 tool wrappers into 14 Fallout.Application.Tools.<Family> projects Jun 29, 2026
@ChrisonSimtian ChrisonSimtian force-pushed the tooling/extract-abstractions branch from 2596d68 to 76b3c99 Compare June 29, 2026 11:29
@ChrisonSimtian ChrisonSimtian force-pushed the tools/split-application-tools branch from d1902bf to fef2e4a Compare June 29, 2026 11:29
ChrisonSimtian and others added 3 commits June 30, 2026 12:14
…Notifications

First family of the tools split (proves the pattern end-to-end on a clean,
dependency-free leaf). Moves Slack, Discord, Teams, Twitter and Mastodon out
of Fallout.Common into a new Application-layer tool project under src/Tools/.

- New project src/Tools/Fallout.Application.Tools.Notifications (net10.0),
  referencing Fallout.Common + Fallout.Tooling.
- Tools keep their Fallout.Common.Tools.<Tool> namespace, so no consumer source
  changes — only a ProjectReference is added where they're used
  (Fallout.Common.Tests).
- Architecture suite governs the new family: it is a loaded, layering-checked
  assembly and must not depend on the Build/Components/Cli layers above it
  (strict, zero-tolerance). Namespace alignment for tool families is deferred,
  so they are intentionally not yet naming-rule subjects (RuntimeLibraries).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ools.*

Bulk move of the dependency-free tool families out of Fallout.Common into
Application-layer projects under src/Tools/ (the cycle-break/cross-dep
families — DotNet, Coverage, Containers, VersionControl — follow next):

- JavaScript (Npm); Testing (xUnit/NUnit/MSpec/Fixie/VSTest/SpecFlow/
  TestCloud/BenchmarkDotNet/dotMemoryUnit); Signing (AzureKeyVault/
  AzureSignTool/SignClient/SignPath/SignTool/NuGetKeyVaultSignTool);
  Packaging (Chocolatey/Squirrel/InnoSetup/MakeNsis/Boots/DotnetPackaging);
  Versioning (GitVersion/MinVer/NerdbankGitVersioning/OctoVersion);
  Cloud (Octopus/Netlify/StaticWebApps); Shell (PowerShell/Pwsh);
  Gaming (Unity); Documentation (DocFX).

- Tools keep their Fallout.Common.Tools.<Tool> namespace (non-breaking);
  consumers (Cli, Components, Cli.Tests, Common.Tests) gain ProjectReferences
  only. Signing carries the Azure Key Vault package refs.
- A few tool attributes integrate with Fallout.Common's internal value-injection
  plumbing, so Signing/Versioning/Shell are granted InternalsVisibleTo (interim
  bridge until value-injection becomes a public Application API).
- Architecture suite governs every family: each must not depend on the
  Components layer (would cycle) or the Cli composition root. Tools reaching up
  into Fallout.Build (ValueInjectionAttributeBase) is documented interim debt of
  the half-onion state.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Completes the tools split: the four families that were coupled to Fallout.Common
or to each other now live under src/Tools/ as well, so Fallout.Common no longer
contains any tool wrappers.

Families:
- DotNet (dotnet/MSBuild/NuGet/Paket/EntityFramework/NSwag/ILRepack/CorFlags/
  VSWhere/MauiCheck/WebConfigTransformRunner) — also home to the three TeamCity
  DotNet/MSBuild settings-extension bridges moved out of Common.
- Coverage (Coverlet/OpenCover/dotCover/ReportGenerator/Codecov/Coveralls/
  CodeMetrics/SonarScanner) — references Tools.DotNet (Coverlet).
- Containers (Docker/Helm/Kubernetes/Pulumi) — references Tools.DotNet (Docker).
- VersionControl (Git/GitHub/GitLink/GitReleaseManager) + LatestGitHubReleaseAttribute;
  adds Octokit.

Cycle-break:
- GitHubTasks.cs split: the pure GitRepository URL/identity helpers (and
  GitHubItemType) move down next to GitRepository as Fallout.Build/VCS/
  GitHubUrlExtensions.cs (namespace Fallout.Common.Git, no Octokit); the
  Octokit-backed client stays in the GitHub tool. ChangeLogTasks now resolves
  the URL helpers via Fallout.Common.Git and no longer depends on a tool.
- TeamCity.cs no longer references the DotCover tool (nameof -> string literals).

Wiring: Cli/Components/_build and the affected test projects gain ProjectReferences;
the four families get InternalsVisibleTo for Common's value-injection internals;
Octokit/Azure.* package refs removed from Fallout.Common (now on the owning
families). Architecture suite governs all 14 families; the two new
Fallout.Common.Git helper types are added to the namespace-drift baseline.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ChrisonSimtian ChrisonSimtian force-pushed the tooling/extract-abstractions branch from 76b3c99 to 8ae03da Compare June 30, 2026 00:15
@ChrisonSimtian ChrisonSimtian force-pushed the tools/split-application-tools branch from fef2e4a to 355b162 Compare June 30, 2026 00:15
ChrisonSimtian added a commit that referenced this pull request Jun 30, 2026
…roject list

Pre-existing staleness, not from the namespace alignment: the snapshot predated the
architecture suite (#9), the Application.Tooling leaves (#10), and the Application.Tools
families (#11), so it was missing those projects and failing on the whole stack. The
generator emits accessors from project/assembly names (unchanged by the namespace work),
so this is a pure catch-up. Also drops the stray committed .received.cs (Verify artifact
that should not be tracked).

Fallout.SourceGenerators.Specs now 6/6.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

target/2026 Releases on the 2026 calendar line

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant