fix: scaffolded-project path assumptions (#283, #284, #287, #288)

[antosubash]

Fixes #283, fixes #284, fixes #287, fixes #288.

Four reports filed against a sm new project scaffold, all one root cause: the framework assumed its own monorepo layout, where a module's directory and assembly are both SimpleModule.<Module>. sm new module scaffolds a bare <Module> for both.

#287 — page bundle 404 on every page load

The client built the bundle URL as _content/SimpleModule.<Module>/…, but an RCL serves its assets under its AssemblyName, so every scaffolded module 404'd before the fallback probe found it.

HtmlFileInertiaPageRenderer now declares the module-name → assembly-name mapping in the page shell, and resolvePage reads it, so the first request goes to the path that actually serves the bundle. Probing stays as a fallback for shells that predate the map, and for an unparseable one.

The same prefix assumption also meant a bare-named module's stylesheet was never linked — BuildModuleCssLinks only matched _content/SimpleModule.*. Module CSS discovery now consults the same mapping.

#283 / #284 — types.ts written into a directory no project owns

extract-ts-types.mjs hardcoded SimpleModule.<Module> as the output project and mkdirSync'd it unconditionally. It now resolves the project directory that actually exists and skips modules with no local source, so:

• a scaffolded module gets its types next to the Pages/ that import them (extract-ts-types.mjs writes types.ts into a SimpleModule.<Module> directory that sm new module never creates #284)
• NuGet-installed modules no longer materialise phantom source trees in a consumer's repo (extract-ts-types.mjs writes types.ts for NuGet-installed modules into the consumer's source tree #283)
• deleting a module no longer resurrects its directory on the next generate:types

Also removes modules/Identity/src/SimpleModule.Identity/, which held only a generated types.ts for a contracts-only module and belonged to no project — the exact artifact #284 describes, committed here.

#288 — Tailwind never recompiled for new pages

Styles/app.css declares the module pages as @source globs, but TailwindBuild did not treat them as inputs, so a new page's utility classes were silently never generated. Module Pages//Views/, the host ClientApp, and the staged module bundles are now inputs, with @(TailwindExtraSourceFiles) as an extension point for hosts that add @source directives of their own.

Verification

• Tailwind build does not re-run when module Pages change, so new utility classes silently never compile #288 — reproduced on unmodified main: added bg-lime-700 to a module page, rebuilt, class absent from app.css. With the fix, bg-fuchsia-800 compiles in.
• extract-ts-types.mjs writes types.ts for NuGet-installed modules into the consumer's source tree #283/extract-ts-types.mjs writes types.ts into a SimpleModule.<Module> directory that sm new module never creates #284 — ran the script against a fixture with all three shapes: src/<Name> (scaffold), src/SimpleModule.<Name> (framework), and a module with no source. Writes into the first two, skips and creates nothing for the third. Re-running against this repo produces zero changes to any existing types.ts.
• Page bundle requested as _content/SimpleModule.<Module>/ but the RCL serves it at _content/<Module>/ — 404 on every page load #287 — the running host emits the map with real assembly names; a browser load makes exactly one bundle request (200), zero console errors. Candidate ordering checked directly for all four cases: declared-and-differing, declared-and-matching, no map, malformed map.
• New integration test InertiaEndpoint_DeclaresAssemblyNameThatServesEachModuleBundle asserts every module with pages is declared and every declared value is a real loaded assembly — it fails outright on the pre-fix shell.
• Full suite green (20 assemblies, 0 failures), npm run check clean, dotnet build 0 warnings.

Note for a follow-up

The scaffold's HostTemplates.AppCss() strips the @source "./_scan/" line, so a scaffolded host never scans the staged bundles of packaged modules — their utility classes would be missing for the same silent reason as #288. Left alone here since it is a separate change to the CLI templates.

[antosubash]

Addressed the review in 10bc18b. Four of six findings fixed; two declined with reasons.

Fixed

• Untracked @source roots — correct, and the more serious of the two Tailwind findings. app.css declares five roots; I had tracked two. Editing packages/SimpleModule.UI left the CSS stale with exactly the Tailwind build does not re-run when module Pages change, so new utility classes silently never compile #288 symptom, in the repo's most-edited shared code. Added the UI and client package roots via new SimpleModuleUiDir/SimpleModuleClientDir properties (npm packages in a scaffold, packages/ in the monorepo), and wired docs/design-system/ through @(TailwindExtraSourceFiles) — which also exercises the extension point.
• _scan glob evaluated too early — correct. Moved the item declaration into CollectModuleAssets, after the Copy. Verified by deleting Styles/_scan/ and rebuilding: TailwindBuild runs in that same build (zero Skipping target "TailwindBuild") and the bundles are re-staged, rather than being missed until a second build.
• Unanchored glob walking bin//obj/ — correct. Anchored to */src/*/Pages/**, which matches both the framework layout and sm new module's. Confirmed module pages are still tracked.
• Fallback probe burying the real error — correct. resolvePage now reports the declared candidate's error instead of the last probe's. Checked all four cases; with {"Invoicing":"Invoicing"} declared, a failure now reports the error from _content/Invoicing/ rather than the 404 from the SimpleModule.Invoicing fallback.

Declined

• Duplicate [Module] name last-write-wins — unreachable. SM0040 is a generator diagnostic with DiagnosticSeverity.Error, so two modules sharing a name fail the build. A runtime throw or warning would be dead code.
• Scaffold strips @source "./_scan/" — a real bug, and the review is right that it is the reason those staged files go unscanned in a scaffold. It is a CLI template change with its own failure mode (a fresh scaffold has no Styles/_scan/, and Tailwind errors on a missing @source path), so it needs the scaffold to create the directory and wants its own verification against a real sm new project. Filed as Scaffolded host strips @source "./_scan/", so packaged modules' Tailwind classes are never compiled #290 and referenced from the comment on CollectModuleAssets so the staging target cannot be misread as covering packaged modules everywhere.

One correction to my own verification. My first attempt to reproduce the untracked-UI-root gap reported a false pass — a leftover mtime from a previous probe, then incidental input churn that reruns Tailwind on many builds in this repo. A clean before/after via timestamps is not reliable here. The finding is settled by inspection instead (none of the committed globs cover packages/SimpleModule.UI), plus MSBuild's own Skipping target "TailwindBuild" after touching that file on the pre-fix tree. After the fix, all five roots report tracked.

Full suite green (20 assemblies, 0 failures), npm run check clean, dotnet build 0 warnings.