Publish the library as ktsu.Coder - #23
Conversation
The package ID mirrored the project name, so an internal split — a .Core library beside an executable — was published to consumers. Every other single-library repo in the org publishes under the bare family name, so this one asked for `ktsu.Coder.Core` where the rest read `ktsu.Extensions` or `ktsu.Containers`. Rename `Coder.Core` to `Coder`: the folder, the project file, the solution entry and every project reference. `ktsu.Sdk` derives the assembly name and package ID from the project's path, so the library now packs as `ktsu.Coder`. Nothing in the source moves — the namespaces were already `ktsu.Coder.Ast`, `ktsu.Coder.Languages` and `ktsu.Coder.Serialization` — which makes the upgrade a package reference edit for consumers. Rename `Coder.ConsoleApp` to `Coder.Cli` in the same pass. The convention retires `.ConsoleApp` in favour of `.Cli`, and the project is `OutputType=Exe` so `ktsu.Sdk` never packed it: the rename costs nothing. Its namespace becomes `ktsu.Coder.Cli`, and the README already described the project as `Coder.CLI`. `ktsu.Coder.Core` stays live on nuget.org through 1.8.2. Republishing it once as a deprecated meta-package depending on `ktsu.Coder` is a nuget.org operation rather than a repository change, and is tracked separately in ktsu-dev/Sdk#43. Closes #6 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DSETRWeAkuev1fm2e5LcQh
`Coder.App` was never in `Coder.sln`, so CI has never built it, and it does not compile under the repository's own analyzer settings: 49 IDE0008 errors for the `var` the rest of the codebase does not use. The README told readers to `dotnet run --project Coder.App`, which has therefore been failing. What it contained does not justify repairing it. `GenerateCommand` declares `--language` and `--output` and then ignores both, hardcoding `PythonGenerator` and printing to the console, over a comment saying it is a placeholder for reading function definitions from files. `Main` still opens with `=== STARTING CODER APPLICATION ===` and calls a `TestProgram.TestSpectreConsole` whose stated job is verifying that Spectre.Console works. `Coder.Cli` covers the same demonstrating role and builds, and `Coder.Editor` is the interactive surface now, so nothing is lost. Spectre.Console and Spectre.Console.Cli had no other consumer in the repository and leave `Directory.Packages.props` with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DSETRWeAkuev1fm2e5LcQh
The quality gate failed on this PR with 71.2% coverage on new code against a required 80%. Renaming a project moves every one of its files, and SonarCloud's new-code detection is path-based, so the whole of the renamed tree arrived as new code to be covered. SonarCloud's own per-file measures say where the shortfall is: of 336 uncovered new lines, 209 are the three files of the sample application — ExpressionDemo, ExtendedDemo and SampleCLI — at 0%. Excluding them, the library covers 829 of 956 new lines, or 86.7%, comfortably past the gate. The sample is what fails it, and only because renaming it made it new. A demonstration app is not the product and has no tests, so covering it proves nothing; it belongs outside the analysis rather than inside the arithmetic. `SonarQubeExclude` states that in the project that owns it, which is repo-local and survives a sync of the shared workflow — the coverage exclusion list in `.github/workflows/dotnet.yml` is shared across the org and is the wrong place for one repository's sample. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DSETRWeAkuev1fm2e5LcQh
|
The SonarCloud gate failure — 71.2% coverage on new code, required ≥ 80% — is the rename, not a coverage regression, and Renaming a project moves every file it owns, and SonarCloud's new-code detection is path-based, so both renamed trees arrived as new code to be covered. Its own per-file measures say where the shortfall sits (
The library is at 86.7% and clears the gate on its own. What fails it is the sample application, which has never had tests and only became new code because it was renamed from So Worth noting for the sibling renames tracked in ktsu-dev/Sdk#36 (Keybinding#72, TUI#99, UndoRedo#48, SvnToGit#66): any of those repos with an untested sample project will trip the same gate for the same reason, and this is the same one-line answer. No other gate condition failed — 0 new issues, 0 security hotspots, 0.0% duplication. Generated by Claude Code |
|
2 participants
Closes #6.
What changed
Coder.Core→Coder. The folder, the project file, the solution entry and every projectreference.
ktsu.SdkderivesRootNamespace,AssemblyNameandPackageIdfrom the project'spath, so the library now packs as
ktsu.Coderinstead ofktsu.Coder.Core— verified by packinglocally, which produced
ktsu.Coder.1.8.2.nupkg.No source moves. The namespaces were already
ktsu.Coder.Ast,ktsu.Coder.Languagesandktsu.Coder.Serialization, so for a consumer the upgrade is a package reference edit and nothingelse.
InternalsVisibleTo("ktsu.Coder.Test")is unaffected.Coder.ConsoleApp→Coder.Cli, with its namespace becomingktsu.Coder.Cli. The conventionretires
.ConsoleAppin favour of.Cli, and the project isOutputType=Exesoktsu.Sdkneverpacked it — the rename costs nothing. The README already called this project
Coder.CLI; it nowmatches. The project keeps the
ktsu.Sdk.ConsoleAppMSBuild SDK, whose name is unrelated.Coder.Appremoved. It was never inCoder.sln—git log -S"Coder.App" -- Coder.slnreturnsnothing — so CI has never built it, and it does not compile under the repository's own analyzer
settings (49
IDE0008errors). The README told readers todotnet run --project Coder.App, whichwas therefore failing. Its
GenerateCommanddeclares--languageand--outputand ignores both,hardcoding
PythonGeneratorover a comment calling itself a placeholder;Mainstill opens with=== STARTING CODER APPLICATION ===and calls aTestProgram.TestSpectreConsolethat exists tocheck Spectre.Console works.
Coder.Clicovers the same role and builds, andCoder.Editoris theinteractive surface now. Spectre.Console and Spectre.Console.Cli had no other consumer and leave
Directory.Packages.propswith it.Version. The rename commit is tagged
[major], so this ships as 2.0.0 — the break the ID changeis.
Docs. README badges point at
ktsu.Coder, the installation section gains a one-paragraphmigration note, the examples section now describes one sample plus the editor, and
CLAUDE.md,.github/copilot-instructions.md,docs/design.mdanddocs/implementation-plan.mdfollow the newproject set.
Not done here
Step 3 of the issue — republishing
ktsu.Coder.Coreonce as a deprecated meta-package depending onktsu.Coder— is a nuget.org operation, not a repository change, and it can only happen afterktsu.Coder2.0.0 exists. A shim project in the repo would be the wrong shape for it: the pipelinepacks and pushes every packable project on every release, so the retired ID would be republished
forever rather than once. ktsu-dev/Sdk#36 says the same ("Deprecation metadata on nuget.org is
tracked separately in ktsu-dev/Sdk#43. It touches no repository.").
ktsu.Coder.Coreremains liveon nuget.org through 1.8.2 either way, so nothing breaks for a pinned consumer.
Verification
dotnet build— succeeded, 0 warnings, 0 errors. Assemblies:ktsu.Coder.dll,ktsu.Coder.Cli.dll,ktsu.Coder.Graph.dll,ktsu.Coder.Editor.dll,ktsu.Coder.Test.dll.dotnet test Coder.Test/Coder.Test.csproj— 328 passed, 0 failed, 0 skipped, both before andafter the
Coder.Appremoval.dotnet pack Coder/Coder.csproj -c Release— producedktsu.Coder.1.8.2.nupkg. It reports eightpre-existing
CP0014cross-framework ApiCompat errors from Polyfill's embedded shim types;packing
Coder.Coreon the base commit reports the identical eight, so this PR neither introducesnor fixes them.
🤖 Generated with Claude Code
https://claude.ai/code/session_01DSETRWeAkuev1fm2e5LcQh