feat: resolve placeholders from consumer dependency pins - #15
Merged
Conversation
The CLI now accepts schemaVersion {2, 3} instead of a single version, so v2
payloads keep parsing. Placeholders may declare `fromDependency`; a payload
using it while declaring schemaVersion 2 is rejected in loadPresetManifest,
because zod strictness alone only protects older CLIs.
resolvePlaceholder gains a middle step between the config value and the static default: a placeholder declaring `fromDependency` takes the consumer's pin for that package, floored via the now-exported parseRangeMin. Only full x.y.z(-pre) floors are used — a partial core like `^6` would render different bytes as the registry moves, so it falls through to the default. The dependency map arrives as data through a new optional renderFile param, so rendering stays pure.
A placeholder value carrying another placeholder's token used to resolve only if the manifest happened to declare the keys in the right order. Substitution now repeats until the output is stable, capped at 10 passes; on the cap it throws CONFIG_INVALID naming the file and every token in the cycle, found by following the values rather than reading the last pass's leftovers (a cycle leaves only one member behind at a time). Values are resolved and pattern-checked once, up front, and still land verbatim through the callback replacement form.
sync, check/drift and status now build the same package.json dependency map once per run (dependencies shadowing devDependencies) and thread it through compose into renderFile, so all three commands compose identical bytes and a check after a sync stays clean. sync reads package.json before the plan pass instead of after it and no longer skips the read when versionSync is off, since rendering needs the map either way — a malformed package.json therefore fails before any managed write on that path too.
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.
Contributes to sidebase/base-config#8
What
A placeholder in a payload manifest can now declare
fromDependency: "<package>". At render time it resolves to the consuming repo's actual pin for that package, stripped to its range floor (^6.19.3becomes6.19.3). Resolution order per placeholder: explicit config value, then the dependency floor, then the staticdefault. Only fullx.y.zfloors count (prereleases included); partial pins like^6, protocol specs, and absent deps fall back to the default so a rendered file never carries a non-reproducible version.Along the way:
CONFIG_INVALIDnaming the file and the tokens involved.schemaVersion2 and 3.fromDependencyrequires 3: an old CLI meeting a v3 payload still gets the clean "upgrade the CLI" message, and the new CLI rejectsfromDependencyunder a v2 manifest so a payload author cannot forget the bump.sync,check, andstatusall feed the same dependency map into rendering (read once per run), so the three commands compose identical bytes.Why
base-config's Dockerfile hardcodes
ARG PRISMA_VERSION=6.19.1while consumers pin their own prisma version; the two drift apart silently and a consumer ahead of the baseline boots its container with an older Prisma CLI than it runs everywhere else (sidebase/base-config#8). With this, the payload declares the intent once and every consumer's rendered ARG tracks its own pin, with--build-argand a config knob still available as overrides.Renders of schemaVersion-2 payloads are byte-identical to the current engine (verified by rendering the base-config fixtures through both engines and comparing tree hashes). Two behavior notes for the release description:
syncnow reads package.json even withversionSync: false, so a malformed package.json fails sync before any write instead of after; and theSCHEMA_UNSUPPORTEDerror'ssupporteddetail is now an array of versions instead of a single number.