[Nx graph] spikersoft-environment consumer audit: all 18 lib consumers are URL-only (100 call sites); only the app needs full environment — migration report, not yet migrating #743

New Issue

2026-07-20T18:44:51Z

spikerj commented

2026-07-20 18:44:51 +00:00

Audit deliverable for the graph-optimization pass (follows #739/#740). Question: which of spikersoft-environment's ~21 direct consumers only need URLs (candidates for shared-api-config-style DI tokens) vs genuinely need the full environment object?

Findings (master @ 5778503)

Every library consumer is URL-only. Field usage across all consumer lib sources, exhaustive:

Field	call sites	consumers
`environment.apiUrl`	81	dev-tools runners (csharp/js/python/sql), decompiler, ipv4, reg-ex, x86-playground, art-studio, trellis-3d, anon-session, clang-runtime, lesson-catalog, playground-visual-progress, progress-sync, activity-tracking
`environment.baseUrl`	13	blog, sponsor, art-studio, trellis-3d, clang-runtime
`environment.signalRUrl`	6	csharp/js/python/sql runners, clang-runtime

No library touches keycloak, production, googleAPIKey, maptilerAPIKey, tileServerUrl, distanceMatrixUrl, calendarApi, or gameServerUrl.

Only the app (spikersoft) genuinely needs full environment — keycloak init (×10), production (×4), map/tile keys, distance-matrix, calendar. Correct as-is; not a migration target.

Two phantom edges: feature-dev-tools-c-runner and feature-dev-tools-cpp-runner declare "@spikersoft/environment" in package.json peerDependencies but have ZERO source imports (their env usage moved into platform-clang-runtime at some point). Nx counts package.json deps as graph edges, so these two show as consumers for free. Removing the two lines drops the hub 21 → 19 direct with no code change — doing that now in a small PR under this ticket.

Recommendation (report, per the don't-force-it call)

Full migration = new SIGNALR_URL (and arguably APP_BASE_URL) tokens in shared-api-config + ~100 call-site edits across 18 libs + provider wiring + spec providers. That's a large, mechanical-but-wide diff, and the churn payoff is modest: spikersoft-environment is a low-churn hub (env shape rarely changes), so unlike #740 this is mostly an architectural-boundary win, not an invalidation win.

Suggested path: don't do a big-bang migration. Adopt the rule "new libs take URLs via shared-api-config tokens, never import @spikersoft/environment", and migrate existing libs opportunistically when they're already being touched (the E-series waves are natural vehicles). Revisit if env-file churn ever starts showing up in nx affected pain.

Audit deliverable for the graph-optimization pass (follows #739/#740). Question: which of `spikersoft-environment`'s ~21 direct consumers only need URLs (candidates for `shared-api-config`-style DI tokens) vs genuinely need the full environment object? ## Findings (master @ 5778503) **Every library consumer is URL-only.** Field usage across all consumer lib sources, exhaustive: | Field | call sites | consumers | |---|---|---| | `environment.apiUrl` | 81 | dev-tools runners (csharp/js/python/sql), decompiler, ipv4, reg-ex, x86-playground, art-studio, trellis-3d, anon-session, clang-runtime, lesson-catalog, playground-visual-progress, progress-sync, activity-tracking | | `environment.baseUrl` | 13 | blog, sponsor, art-studio, trellis-3d, clang-runtime | | `environment.signalRUrl` | 6 | csharp/js/python/sql runners, clang-runtime | No library touches `keycloak`, `production`, `googleAPIKey`, `maptilerAPIKey`, `tileServerUrl`, `distanceMatrixUrl`, `calendarApi`, or `gameServerUrl`. **Only the app (`spikersoft`) genuinely needs full environment** — keycloak init (×10), `production` (×4), map/tile keys, distance-matrix, calendar. Correct as-is; not a migration target. **Two phantom edges:** `feature-dev-tools-c-runner` and `feature-dev-tools-cpp-runner` declare `"@spikersoft/environment"` in package.json peerDependencies but have ZERO source imports (their env usage moved into `platform-clang-runtime` at some point). Nx counts package.json deps as graph edges, so these two show as consumers for free. Removing the two lines drops the hub 21 → 19 direct with no code change — doing that now in a small PR under this ticket. ## Recommendation (report, per the don't-force-it call) Full migration = new `SIGNALR_URL` (and arguably `APP_BASE_URL`) tokens in `shared-api-config` + ~100 call-site edits across 18 libs + provider wiring + spec providers. That's a large, mechanical-but-wide diff, and the churn payoff is modest: `spikersoft-environment` is a **low-churn** hub (env shape rarely changes), so unlike #740 this is mostly an architectural-boundary win, not an invalidation win. Suggested path: don't do a big-bang migration. Adopt the rule "new libs take URLs via `shared-api-config` tokens, never import `@spikersoft/environment`", and migrate existing libs opportunistically when they're already being touched (the E-series waves are natural vehicles). Revisit if env-file churn ever starts showing up in `nx affected` pain.

spikerj commented

2026-07-20 19:09:51 +00:00

Audit delivered in the ticket body; the one actionable piece (phantom c/cpp-runner edges) merged in spikersoft-angular PR #472 — env hub is now 19 direct consumers. Recommendation of record: no big-bang migration; new libs take URLs via shared-api-config tokens, existing consumers migrate opportunistically when touched. Closing as report-complete — reopen if a dedicated migration wave ever gets scheduled.

Audit delivered in the ticket body; the one actionable piece (phantom c/cpp-runner edges) merged in spikersoft-angular PR #472 — env hub is now 19 direct consumers. Recommendation of record: no big-bang migration; new libs take URLs via `shared-api-config` tokens, existing consumers migrate opportunistically when touched. Closing as report-complete — reopen if a dedicated migration wave ever gets scheduled.

spikerj closed this issue

2026-07-20 19:09:58 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#743