Move CodeGen/ into a shared source-generator toolkit package #192

Activity

1. matt-edmondson

   added

   enhancementNew feature or requestNew feature or request

   on Aug 27, 2026
2. matt-edmondson commented on Aug 27, 2026

   

   matt-edmondson

   on Aug 27, 2026 – with Claude

   ContributorAuthor

   More actions

   Decision recorded: (a), a new ktsu-dev/SourceGeneratorToolkit repo

   Per the acceptance criteria, the packaging decision is (a). The reasoning in the issue holds: ktsu.CodeBlocker ships eight target frameworks down to netstandard2.0 with one small dependency, and coupling its release cadence to Roslyn's — which moves fast enough that this code pins Microsoft.CodeAnalysis 5.9 — is the wrong trade.

   The extraction is done and verified. I can't create the repo.

   create_repository against the org returns:

   POST https://api.github.com/orgs/ktsu-dev/repos: 403 Resource not accessible by integration
   

   So the last step needs someone with org permissions. Everything up to it is finished, built and tested locally, and attached to the session as a tarball with the git history intact:

   tar xzf SourceGeneratorToolkit.tar.gz
   cd SourceGeneratorToolkit
   git remote add origin https://github.com/ktsu-dev/SourceGeneratorToolkit.git
   git push -u origin main

   27 tests, 0 failures. Clean under the ktsu.Sdk analyzers and under the Sonar analyzers.

   What moved

   Exactly the table in the issue: GeneratorBase.cs, MetadataFile.cs, DiagnosticCatalog.cs, CSharpKeywords.cs, and GeneratorHarness.cs. Namespace ktsu.SourceGeneratorToolkit. Nothing physics-specific came with it, and the doc comments that referred to this repository's own history have been restated in terms the package can stand behind.

   GeneratorHarness ships in the package, not in its test project — a consumer testing their own generator needs it, and it carries the BundleAnalyzerDependencies=false knowledge the issue flagged as worth not rediscovering.

   Decisions made along the way

   • ktsu.Sdk, not plain Microsoft.NET.Sdk — the issue asked for this to be deliberate. Semantics.SourceGenerators is IsPackable=false; this one publishes, so it wants the SDK's packaging metadata and release pipeline. TargetFrameworks is overridden to netstandard2.0 only: a Roslyn component loads into the compiler, and the rest of the SDK's default set would be assemblies the analyzer host can't load.
   • Microsoft.CodeAnalysis.* is PrivateAssets="all"; ktsu.CodeBlocker and System.Text.Json are not — the analyzer host supplies Roslyn and a consuming generator references it at whatever version it builds against, but consumers write templates and models against the other two.
   • Four analyzer findings came with making these types public rather than internal, and are fixed rather than suppressed: two CA1062 argument guards, a cached JsonSerializerOptions for CA1869, and a range instead of Substring.

   Two things the repo will need that I couldn't do either

   • NuGet publishing secrets. The copied dotnet.yml is the shared ktsu pipeline and expects the usual org secrets; I can't set those.
   • MetadataFile.FindLocation's scoped overload is newer than what's on main here — it came from SEM001 and SEM003 report without a source location #193 (in Get ubuntu-latest green, and clear the three codegen follow-ups #197, unmerged). The extracted copy has it.

   What's still open here

   The repoint. Semantics.SourceGenerators can't consume the package until ktsu.SourceGeneratorToolkit 1.0.0 is on NuGet — the same sequencing #187 had with ktsu.CodeBlocker 1.3.0. Once it publishes, the change here is mechanical: add the PackageReference, delete CodeGen/, delete Semantics.Test/Quantities/GeneratorHarness.cs, and repoint the using. Semantics.SourceGenerators is then Models/, Metadata/, Generators/ and the Semantics-specific bindings, which is the third acceptance criterion, and #181 can close.

   So: criterion 1 met, criteria 2–5 blocked behind creating the repo and publishing the package.

   ---

   Generated by Claude Code
3. matt-edmondson commented on Sep 8, 2026

   

   matt-edmondson

   on Sep 8, 2026 – with Claude

   ContributorAuthor

   More actions

   The repo exists and the packages are published

   ktsu-dev/SourceGeneratorToolkit was created and filled. Both packages are live at 1.0.0:

   • ktsu.SourceGeneratorToolkit — GeneratorBase/GeneratorBase<T>, MetadataFile/MetadataSet, DiagnosticCatalog/DiagnosticReporting, CSharpKeywords
   • ktsu.SourceGeneratorToolkit.Testing — GeneratorHarness

   The repoint here is #207.

   One change from the plan recorded above: two packages, not one

   The earlier comment said GeneratorHarness ships in the package rather than in a test project. It does ship — but as a sibling package, not inside the analyzer one.

   GeneratorHarness reads metadata off disk (Directory.GetFiles, File.ReadAllText). RS1035 bans exactly those APIs for code that runs in an analyzer host, and EnforceExtendedAnalyzerRules is what turns that rule on. Putting the harness in the main package would have meant suppressing RS1035 project-wide — and that suppression would then also cover GeneratorBase and MetadataFile, which genuinely do run inside the compiler. A future contributor adding a file read to GeneratorBase would get no warning.

   Splitting keeps the rule on where it matters and off where it doesn't. The intent of the original decision is preserved: a consumer testing their own generator gets the harness from NuGet rather than rediscovering it, and it still carries the BundleAnalyzerDependencies=false knowledge — documented in the type's own XML docs and in the README.

   Acceptance criteria

   • Packaging decision made and recorded — (a), a new repo, as decided above.
   • CodeGen/ and GeneratorHarness live in the chosen package; this repository consumes them (Consume the extracted source-generator toolkit from its package #207).
   • Semantics.SourceGenerators contains only Models/, Metadata/, Generators/ and the Semantics-specific bindings (SemanticsGenerator, SemanticsDiagnostics, the physics half of Emit).
   • Generated output under Semantics.Quantities/Generated/ unchanged — byte-identical, git status clean after a full rebuild.
   • Epic: extract and generalize the code generation stack so other projects can share it #181 can be closed.

   Decisions taken along the way

   • ktsu.Sdk, not plain Microsoft.NET.Sdk — the issue asked for this to be deliberate. Semantics.SourceGenerators is IsPackable=false; these publish, so they want the SDK's packaging metadata and release pipeline. TargetFrameworks is overridden to netstandard2.0 only: a Roslyn component loads into the compiler, and the SDK's default set would be assemblies the analyzer host cannot load.
   • Microsoft.CodeAnalysis.* and System.Collections.Immutable are PrivateAssets="all"; ktsu.CodeBlocker and System.Text.Json are not. Verified against the built .nuspec: the main package's only dependencies are ktsu.CodeBlocker, System.Text.Json, System.Memory and System.Threading.Tasks.Extensions. No Roslyn dependency flows.
   • Analyzer findings from making the types public were fixed, not suppressed — Ensure.NotNull guards, a cached JsonSerializerOptions (CA1869), a range instead of Substring, and MetadataSet converted from a primary constructor so its guard could run.

   39 tests, 0 failures; clean under both the ktsu.Sdk analyzers and the Sonar analyzers.

   Two things that bit, worth recording

   • icon.png is LFS-tracked. git-lfs was not installed in the environment that made the first commit, so what landed was the pointer text with no object behind it, and every checkout with lfs: true failed. Fixed by installing git-lfs and pushing the object.
   • Dependabot auto-merged a bump mid-run. A System.Collections.Immutable 10.0.1 → 10.0.11 PR merged while the first pipeline was being re-run, so the release job tried to push its metadata commit onto a main that had moved and was rejected non-fast-forward. Re-running a run pinned to a stale SHA cannot fix that — the pipeline had to be dispatched afresh on the current tip.

   ---

   Generated by Claude Code
4. matt-edmondson

   closed this as completedin #207on Sep 8, 2026
5. Damon3000s

   added a commit that references this issue on Sep 15, 2026

   refactor: consume the extracted source-generator toolkit from its pac…

   ...

   This issue will close once commit d1cdded is merged into the 'main' branch.

   d1cdded