Chore/jsf kit v1 - #1270
Open
jordividaller wants to merge 2 commits into
Open
Conversation
Kit v1.0.0 removes the `nextVersion` flag and runs schemas that don't
declare a version in `x-rmt-meta` on the v1 engine (the pre-1.0 default
was v0). To keep behaviour stable while staying ready for the switch:
- local static schemas (json-schemas/) now declare
`x-rmt-meta: { jsfOldVersion: true }` at the source, since they were
authored against the v0 engine
- `createHeadlessForm` stamps undeclared schemas with a configurable
engine fallback, defaulting to v0 (the historical behaviour)
- new `jsfEngineFallback` prop on `<RemoteFlows>` lets consumers flip
the fallback to v1 once the gateway starts serving undeclared v1
schemas
Schemas that declare their version in `x-rmt-meta` (all gateway
responses today) are unaffected by the fallback.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The region fields schema comes from the API, which will eventually serve it as jsf v1. Both engines now work, selected by the schema's own x-rmt-meta declaration: - only pass the region schema's own values to its handleValidation: the v1 engine enforces additionalProperties, so the static fields' values would be rejected as forbidden properties (v0 silently ignored them) - synthesize the yupError entries from formErrors when the v1 engine validated the schema (it returns no yupError), keeping handleValidation's public return shape identical on both engines - declare the static cost calculator schema as v0 in x-rmt-meta (it was authored against the v0 engine and its yup validationSchema is public API); it no longer depends on any engine default Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
📦 Bundle Size Report
Size Limits
Largest Files (Top 5)
View All Files (421 total)
✅ Bundle size check passed |
Contributor
📊 Coverage Report✅ Coverage increased! 🎉
Detailed BreakdownLines Coverage
Statements Coverage
Functions Coverage
Branches Coverage
✅ Coverage check passed |
Contributor
|
Deploy preview for adp-cost-calculator ready!
Deployed with vercel-action |
Contributor
|
Deploy preview for remote-flows ready!
Deployed with vercel-action |
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.
What
Upgrades @remoteoss/remote-json-schema-form-kit from 0.0.23 to 1.0.0 and prepares the SDK for the v1 engine rollout.
Why
Kit 1.0.0 ships one breaking change: the nextVersion flag is removed, and a schema that doesn't declare a version in x-rmt-meta now runs on the v1 engine (the pre-1.0 default was v0). Schemas that declare their version ({ jsfOldVersion: true } → v0, { jsfVersion: '1' } → v1) behave exactly as before.
The gateway stamps x-rmt-meta on its schema responses (verified on partners sandbox: cost-calculator region fields and contract_details both return { jsfOldVersion: true }), so API-served schemas are unaffected. The risk was everything that silently relied on the old default: our local static schemas and any consumer-provided schema.
How
Behavior-preserving upgrade:
All local static schemas (the json-schemas/ dirs of 5 flows + the Cost Calculator's static schema) now declare x-rmt-meta: { jsfOldVersion: true } at the source — they were authored against the v0 engine.
createHeadlessForm stamps undeclared schemas with a configurable engine fallback, defaulting to 'v0' (the historical behavior).
New public prop jsfEngineFallback: 'v0' | 'v1' on (documented in the README) lets consumers flip the fallback once the gateway starts serving undeclared v1 schemas; we'll flip the default in a future release.
Cost Calculator v1 readiness:
The region fields schema comes from the API and will eventually be served as v1. The region validation path now works on both engines, selected automatically by the schema's own x-rmt-meta — no code change needed on our side when the API switches:
The region handleValidation only receives the region schema's own values: the v1 engine enforces additionalProperties, so static-field values would be rejected as forbidden properties (v0 silently ignored them).
When the v1 engine validated the schema (it returns no yupError), the yup entries are synthesized from formErrors, keeping handleValidation's public return shape identical on both engines.
The static schema (and its public yup validationSchema) deliberately stays on v0; migrating it is a separate effort gated on an API deprecation decision.
Known behavioral difference, covered by a test: the v1 engine doesn't require nested fieldset fields when the parent object is absent from the root required (v0's yup casted absent objects to {} and fired the inner requireds). This follows strict JSON Schema semantics; if those errors are wanted, the schema should list the fieldset in its root required.
Testing
876/876 unit tests green (10 new: engine-fallback behavior, v1 region fields fill/submit/validation, formErrorsToValidationErrors helper)
Full local CI green (build, format, exports, lint, type-check, tests, bundle size within limits)
E2E: 4/5 specs pass — identical to main. onboard-basic-employee.spec.ts fails the same way on main with kit 0.0.23 (pre-existing sandbox/spec issue, not a regression)