Repository navigation
fix: make urlcode init --with bundle-only, auto-resolving extension-bundles@v<core> - #526
Merged
Merged
Conversation
…undles@v<core> Hard rule: --with no longer reaches npm-package distribution for extensions at all. When --bundle-release is omitted, it now auto-resolves extension-bundles@v<running core version> (bundle releases are immutable exact tags with no semver range to default against, unlike the retired npm path) and refuses cleanly if that release doesn't exist, instead of silently falling back to a permanently-frozen npm channel. - init-with.ts: --with's ScaffoldRequest always sets distribution: 'bundle'. Bundle installation/coreVersion compatibility (matching loadExtensionBundle's own later check) now happens eagerly during --with, not only discovered when the site is served. - ui/auth/admin's scaffold() keep their npm-distribution branch: it's still reachable from each package's own separate, documented standalone quickstart CLI (urlcode-auth init, urlcode-admin init), a source-build tool distinct from --with. Caught and fixed a regression where an earlier, too-broad pass removed that branch entirely and silently broke those tools. - extension-bundles.ts: export runningCoreVersion for reuse by --with's auto-resolve. Converted 6 test files' fixtures from fake npm packages to signed bundles (synthetic where cheap, or packed from this checkout's real compiled packages via npm pack + a local staged install, mirroring scripts/prepare-extension-bundles.ts's actual dependencySet/entryFor conventions and its own git+npm-install approach, minus the git-archive step). Filed while testing, not fixed here (both need a real design decision): - #524: composing ui + auth/admin bundles gives each its own independently extracted copy of ui, so a Markup instance created by auth's embedded ui copy fails `instanceof Markup` against the standalone ui bundle's class. Confirmed against the real dependencySet/entryFor conventions, not a test artifact -- a genuine, previously-undiscovered bug in live-served composed bundle sites. One test (workspace-scaffold.integration.ts) is skipped pointing at this issue. - #522 (filed by a peer session investigating urlcode-ai): no bundle path exists for ui's presentation primitives alone, only full extension activation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
jimhoyd
enabled auto-merge (squash)
September 23, 2026 19:34
…st resource contention)
- packages/store/test/core-contract.test.ts: drop npm pack/install staging
entirely -- store has no runtime dependencies, so its bundle fixture can
just tar dist/ directly. This also removes the heavy synchronous work that
was starving sibling test files' worker threads on CI (test/query.test.ts
"Configuration worker resource limit or failure").
- test/workspace-scaffold.integration.ts: reuse scripts/release-npm.ts's
npmCommand() helper instead of spawnSync('npm.cmd', ...) directly, fixing
a Windows-only spawn failure (status: null).
- test/init-with.test.ts, test/workspace-scaffold.integration.ts: account for
quote() wrapping destination paths containing backslashes in single quotes
on Windows, which two regex assertions didn't expect.
Refs #526
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
windows-latest's file I/O (tar extraction, junction creation per bundle install) runs several times slower than Linux/macOS for this job. The rewritten test/workspace-scaffold.integration.ts does ~11 initWith() bundle installs plus 2 CLI subprocess runs in its last test alone -- comfortably under 10 minutes on Linux/macOS (workspace-integration (windows-latest, 24) was cancelled mid-run at the 10-minute job timeout after already completing 4 of 6 tests: init --with ui,auth,admin alone took 221s on Windows vs ~17s locally on macOS). Refs #526 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This was referenced Sep 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Hard rule:
urlcode init --withno longer reaches npm-package distribution for extensions at all — bundle-only. Extension npm packages were already retired from publication (#513/#516 removed them from the release pipeline), but--withitself still silently defaulted to npm-package resolution whenever--bundle-releasewas omitted — a permanently frozen, deprecated channel that only drifts further fromcoreon every release. This traced back from a real consumer (urlcode-ai) that ended up pinned to it.Changes
--withalways requests bundle distribution now. When--bundle-releaseis omitted, it auto-resolvesextension-bundles@v<running core version>(bundle releases are immutable exact tags — there's no semver range to default against, unlike the retired npm path) and refuses cleanly if that release doesn't exist, rather than silently falling back to npm.installBundle's result is checked against the running core version during--withitself now, matchingloadExtensionBundle's own later runtime check — an incompatible--bundle-releaseis caught before anything is written, not only discovered once the site is served.urlcode-auth init/urlcode-admin initkeep their npm-based behavior unchanged. These are separate, documented standalone quickstart CLIs (source-build tooling, distinct from--with) that legitimately still pin npm peers. I initially removed the npm branch fromui/auth/admin's sharedscaffold()too broadly, which silently broke these; caught it viapackages/auth's own test suite and restored the branch, now reachable only from these two CLIs, never from--with.npm pack+ a local staged install) mirroringscripts/prepare-extension-bundles.ts's actualdependencySet/entryForconventions, minus the git-archive step.Filed while testing, not fixed here
Both need a real design decision, not a quick patch:
ui+auth/adminbundles gives each its own independently-extracted copy ofui, so aMarkupinstance created byauth's embeddeduicopy failsinstanceof Markupagainst the standaloneuibundle's class. Confirmed against the realdependencySet/entryForconventions — a genuine, previously-undiscovered bug in live-served composed bundle sites, not a test artifact. One test inworkspace-scaffold.integration.tsis skipped pointing at this issue.urlcode-ai): no bundle path exists forui's presentation primitives alone, only full extension activation.Verification
npm run typecheck(root + ui/auth/admin/store workspaces)npm run verify— full suite, all workspaces: 0 failures (772+90+213+67+32+7+5 = 1186 passing, 2 intentional skips: pre-existing SQLite gate + the extension-bundles: composing ui + auth/admin breaks cross-bundle instanceof checks (Markup rendering fails) #524 pointer above)eslintclean on every changed file