Repository navigation
[P5] Decide bridge strategy for existing NUKE consumers #35
Description
Question
How do existing NUKE users — those with build scripts containing `using Nuke.Common; class Build : NukeBuild` — migrate to Fallout?
Constraint
We don't own the `Nuke.*` package IDs on nuget.org. Matt does. So we cannot publish typeforwarding shims under `Nuke.Common` on nuget.org. We could ship them on GitHub Packages but users would need to opt into our feed.
Options
A. Roslyn codefix in Fallout.Common
Ship an analyzer that detects `using Nuke.*` and offers a one-click rewrite. Lowest user effort post-install. Doesn't help users who haven't installed Fallout yet (chicken-and-egg).
B. Standalone migration CLI tool
`dotnet tool install -g Fallout.Migrate` → run in repo → rewrites `using` directives, replaces PackageReferences, suggests bootstrap script updates. Heavier lift to build but works end-to-end.
C. Manual migration guide
Step-by-step doc, optionally with sed/PowerShell scripts users can copy. Zero tooling work, highest user effort.
D. Type-forwarding shim packages
Ship `Fallout.Compat.Nuke.Common` package that re-exports `Fallout.Common` types under the `Nuke.Common` namespace via `[TypeForwardedTo]`. Users PackageReference this single bridge and old `using` directives keep working. Trade-off: keeps the NUKE namespace alive forever.
E. Hybrid (recommended)
- A (codefix) for the simple cases
- C (manual guide) for documentation
- B (CLI tool) deferred until demand justifies it
- D explicitly avoided — we want the namespace transition clean
Done when
- Decision documented here
- Implementation issue(s) opened for the chosen approach
- Migration timeline drafted (when does `Nuke.*` support sunset?)
Activity
ChrisonSimtian commentedon May 19, 2026
Chosen strategy: A + B + C + D (kitchen sink)
Going broader than the originally recommended hybrid. Existing NUKE users are an enterprise audience; migration friction has to be near-zero or they stay on
nuke-build/nuke10.x. Accepting the trade-off of keepingNuke.*namespace surface area alive longer than ideal in exchange for genuine drop-in migration.What ships
Fallout.Compat.Nuke.Commonetc. — re-exportFallout.Commontypes under theNuke.Commonnamespace via[TypeForwardedTo].using Nuke.*keeps compiling.dotnet tool install -g Fallout.Migrate→ rewritesusingdirectives,PackageReferences,[Nuke...]attributes, and bootstrap scripts in one pass.using Nuke.*.docs/migration/from-nuke.md.Constraint check: nuget.org
The
Nuke.*package IDs on nuget.org are still owned upstream. The shim packages therefore ship asFallout.Compat.Nuke.<X>— notNuke.<X>. The compat package's internal namespace isNuke.<X>(so consumerusing Nuke.X;keeps resolving), but the package ID is Fallout-prefixed. ~95% of the source-compatibility value without needing nuget.org ownership.Sunset timeline (proposal)
Follow-up
Fallout.Compat.Nuke.*) — opening separately.Fallout.Migrate) — opening separately.TypeForwardedTocleanly.ChrisonSimtian commentedon May 19, 2026
Amendment: shim packages reuse the
Nuke.*IDs on our GH Packages feedThe earlier strategy comment proposed
Fallout.Compat.Nuke.<X>as the shim package IDs to avoid colliding with upstream's nuget.org ownership. Refined position: GitHub Packages is our own feed —ChrisonSimtian/Nuke.Commonlives in a different ID-space fromnuget.org/Nuke.Common. So we can simply publishNuke.<X>packages on our GH feed without any collision.This collapses three things into a much cleaner bridge:
Revised shim architecture (β)
The codebase still renames internally to
Fallout.*. We then publish two parallel package families to our GH Packages feed:Fallout.<X>11.x — canonical, real types inFallout.*namespace.Nuke.<X>11.x — depends onFallout.<X>, contains only[assembly: TypeForwardedTo(typeof(Fallout.<X>.SomeType))]declarations, exposes theNuke.<X>namespace surface.What that means for a NUKE consumer
Migration becomes:
nuget.config.<PackageReference Include="Nuke.Common" Version="11.0.0" />.using Nuke.Common;keeps compiling.No package ID change. No namespace change in their source. They can later migrate to native
Fallout.<X>at their own pace — or stay on theNuke.<X>shim indefinitely.Scope boundary
The
Nuke.<X>packages on our GH Packages feed are bridge artifacts, not a successor brand. The successor identity isFallout— repo, docs, comms, eventual nuget.org publication. Publishing transientNuke.<X>shim packages on a private feed during migration is consistent with the spirit of the original maintainer's "name can't be carried over" position.Impact on related issues
Nuke.<X>, notFallout.Compat.Nuke.<X>. Updating the issue body to reflect this.Fallout.MigrateCLI) —PackageReferencerewriting becomes optional. The CLI's default path: leaveNuke.<X>IDs alone, just bump versions and add the GH Packages feed. A--rename-packagesflag offers the harder cutover.Nuke.<X>(easiest)" vs "cut over toFallout.<X>".docs(rebrand): capture namespace mapping and bridge strategy (#53)