Move more prefix mappings to use virtual networks#5029
Draft
backspace wants to merge 18 commits into
Draft
Conversation
Contributor
Preview deploymentsHost Test Results 1 files ± 0 1 suites ±0 1h 35m 32s ⏱️ -3s Results for commit b3f0a80. ± Comparison against earlier commit 7abb563. For more details on these errors, see this check. Realm Server Test Results 1 files ±0 1 suites ±0 12m 43s ⏱️ +45s Results for commit b3f0a80. ± Comparison against earlier commit 7abb563. |
e604393 to
099a57c
Compare
RealmPaths takes an optional virtualNetwork constructor arg and routes inRealm's cross-form URL/prefix normalization through vn.toURL when one is present, falling back to the deprecated cardIdToURL when absent. The in-class runtime-common callers (the Batch in index-writer, IndexRunner, RealmIndexQueryEngine.loadLinks, Realm itself, and VirtualNetwork's own urlMappings paths) pass their VN. Module-level instances (baseRealm, baseRealmPath) and free-function callers stay on the fallback. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
codeRefWithAbsoluteIdentifier, resolveAdoptedCodeRef, and resolveAdoptsFrom take an optional virtualNetwork param and route prefix resolution through it, falling back to the deprecated module-level resolveCardReference / cardIdToURL when absent. loadCardDef derives the VN from its existing opts.loader (via Loader.getVirtualNetwork()), so callers don't need to pass it. The realm-index-query-engine codeRefWithAbsoluteIdentifier sites now pass this.#realm.virtualNetwork. The remaining runtime-common callers (commands.ts, file-serializer's resolveChildDef) stay on the fallback until their own threading lands. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
….virtualNetwork SerializeOpts gains an optional virtualNetwork field. Both maybeRelativeReference closures in serializeCard / serializeFileDef use it to consult VN.isRegisteredPrefix / VN.toURL for prefix resolution, falling back to the deprecated module-level resolver when opts doesn't carry one. card-serialization stays single-edge w.r.t. card-api (no import cycle introduced); callers thread the VN through opts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
resolveQueryAndRealm gains a virtualNetwork param and uses it for relativeTo derivation and the existing normalizeQueryDefinition param. ensureQueryFieldSearchResource (which already holds a CardStore) passes store.virtualNetwork through. No import cycle introduced; the VN reaches the closure via the CardStore interface that query-field-support already depends on. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…li green paths.ts only uses VN.toURL, so declaring an inline structural interface for that single method lets RealmPaths accept any VirtualNetwork without importing the type from ./virtual-network. The direct import added a new dependency edge that pulled base-realm URL imports into consumers like @cardstack/boxel-cli, whose tsc surfaced existing TS2307 errors for https://cardstack.com/base/* specifiers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… args MarkdownTemplate's Signature gains an optional cardReferenceVirtualNetwork arg; the resolveUrl helper consults it for prefix/RRI resolution and falls back to the deprecated module-level resolveCardReference when absent. RichMarkdownField's embedded/atom/edit components add a virtualNetwork getter (virtualNetworkFor(this.args.model)) and pass it through the MarkdownTemplate invocation alongside cardReferenceBaseUrl. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…lNetwork serialize/codeRefAdjustments accept SerializeOpts.virtualNetwork and use it for baseURL derivation and the module-href resolution, falling back to the deprecated module-level resolveCardReference / cardIdToURL when absent. deserializeAbsolute and the queryableValue/formatQuery path stay on the fallback (they don't currently receive opts). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…etwork arg CodeMirrorEditorSignature gains an optional cardReferenceVirtualNetwork arg; resolveUrl, _resolvedCardUrls, and the card-target resolver use it when present, falling back to resolveCardReference. RichMarkdownField's edit component forwards its existing virtualNetwork getter alongside cardReferenceBaseUrl. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The five sites in spec.gts that resolved a card id / module ref now go through virtualNetworkFor(instance) and pass the resulting VN to codeRefWithAbsoluteIdentifier / VN.toURL, falling back to cardIdToURL / resolveCardReference when no VN is available. Covers the PopulateFieldSpecExampleCommand helper, the Isolated and Edit components' absoluteRef getters, the moduleHref computed field, and the GenerateExamplesForFieldSpecCommand menu-item action. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…eCard entry points CardService.serializeCard now seeds opts.virtualNetwork from this.network.virtualNetwork, so every host caller that goes through the service (commands, store consumers, routes) automatically threads the VN to the base card-serialization path. The two direct api.serializeCard / api.serializeFileDef call sites (StoreService.serializeFileDefAsDocument and routes/render/meta) populate the same field explicitly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
isRealmIndexCardId and isRealmIndexCard now take an optional virtualNetwork param and route both the RealmPaths constructor and the cardId-to-URL conversion through it, falling back to cardIdToURL when absent. The host call sites (operator-mode-state-service, the detail- panel and stack-item operator-mode components, and the render/html route) inject @service network and pass this.network.virtualNetwork. The base menu-items.ts caller is in card-api's circular import set and stays on the fallback for now. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ModuleSyntax takes an optional virtualNetwork constructor arg and uses it for url normalization, the external classRef lookup, and the makeNewField call from addField. makeNewField now accepts a virtualNetwork option and threads it into its codeRefWithAbsoluteIdentifier comparisons and the relativeFieldModuleRef resolution. Host callers (module-contents resource, module-contents-service, schema-editor, and add-field-to-card-definition command) pass this.network.virtualNetwork. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ListingPathResolver, PlanBuilder, planModuleInstall, planInstanceInstall, and resolveTargetCodeRef all accept an optional VirtualNetwork and use it for both RealmPaths construction and the cardIdToURL / resolveAdopted CodeRef resolutions, falling back to the deprecated module-level resolver when absent. The host listing-install command passes this.network.virtualNetwork through. The module-level baseRealmPath constant and the plan-install unit tests stay on the fallback. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The remaining host internalKeyFor callers (show-card command, search-
content / type-picker / playground-panel components, render/{html,
meta, types} and module routes) now thread the network service's VN.
TypePicker, RenderTypesRoute, ShowCardCommand, search-content and
playground-panel gain @service network; html.ts replaces the module-
level CARDS_GRID_INTERNAL_KEY constant with an inline lazy computation
so both sides of the comparison use the same VN-resolved key; module.ts's
free buildModuleModel / getTypes functions reach the VN via the
ModuleModelContext they already receive.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Promote `ROOT_TYPE_KEYS` (a module-level Set keyed by internalKeyFor output) into a function `getRootTypeKeys(virtualNetwork?)` so the keys match whichever realm-mapping context the caller is in. Add an optional `virtualNetwork` parameter to `getBaseFilterTypeKeys` and `hasNonRootBaseFilter` and thread it through TypeSummariesResource via its injected NetworkService. In file-def-attributes-extractor, route the `internalKeyFor` call through the existing `#network` field. Also tidy two import-order errors flagged by lint in earlier-touched files. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Mirror the change in TypeSummariesResource: pass `this.network.virtualNetwork` into the `internalKeyFor` call that produces selectedTypeIds for buildRecentsQuery. Keeps the keys consistent with whichever realm-mapping context the calling component sees. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
When a plural link reference fails to load, the error branch walked the WatchedArray looking for the slot whose unresolved reference matched. The lookup went through the deprecated module-level `resolveCardReference`, so the comparison key was always built from the global registry, while the value it was being compared against (`reference`, computed via `resolveRef(store, …)` on the success path just above) honored the store's VirtualNetwork. Route both sides through the same `resolveRef(store, …)` so the comparison key matches in either prefix-form or URL-form depending on the store's network mapping. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
c16086c to
7abb563
Compare
`codeRefAdjustments` resolves a card's `module` field for serialization, relying on the deprecated `resolveCardReference` to throw on bare specifiers (e.g. `@cardstack/boxel-host/commands/foo`) that aren't registered as a realm-prefix mapping — the surrounding try/catch then leaves the original reference unchanged so module loaders that operate on the shim importMap can resolve it. VN's `resolveURL` is by design more permissive than the deprecated resolver: `resolveRRI` allows bare names like `card` to resolve against a scoped base, so VN doesn't throw on bare specifiers. Wrap the resolver inside `codeRefAdjustments` so the VN-aware path mirrors the deprecated throw exactly for bare specifiers that aren't matched by any registered prefix — keeping the catch's "leave the reference unchanged" outcome. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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
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.
This is a continuation of #4954.