feat: flip 6 form schemas to canonical @meshery/schemas (#866 phase 3)#1482
Open
leecalcote wants to merge 3 commits intomasterfrom
Open
feat: flip 6 form schemas to canonical @meshery/schemas (#866 phase 3)#1482leecalcote wants to merge 3 commits intomasterfrom
leecalcote wants to merge 3 commits intomasterfrom
Conversation
Part of the meshery/schemas#866 cascade. Once `@meshery/schemas` ships the canonical RJSF form schemas (PR meshery/schemas#867 + follow-ups), Sistent flips its hand-authored `src/schemas/<construct>/schema.tsx` files to re-exports from `@meshery/schemas`. Phase 1 of #866 ships only `CatalogPublishRjsfSchemaV1Beta2` and `CatalogPublishRjsfUiSchemaV1Beta2`, so: - publishCatalogItem/{schema,uiSchema}.tsx: fully flipped to re-export from `@meshery/schemas`. The published Sistent export names (`publishCatalogItemSchema`, `publishCatalogItemUiSchema`) are unchanged; only the source flips. Consumers in `meshery` and `meshery-cloud` keep working without source changes. - The other 9 schema.tsx files (importDesign, importFilter, importModel, createAndEditEnvironment, createAndEditWorkspace, kubernetesCredential, grafanaCredential, prometheusCredential, helmConnection) are left in place but each gets a TODO header referencing #866 and the canonical name to use once Phase 2 follow-up PRs ship those forms. - helpAndSupportModal stays Sistent-local — there's no canonical construct upstream. Bumps `@sistent/sistent` to 0.22.0 (minor) to reflect the source-of- truth change for `publishCatalogItem`. The `@meshery/schemas` dependency range is unchanged (`^1.2.7`). The flipped re-export will fail to type-check until the consuming `@meshery/schemas` release ships PR #867 and exports `CatalogPublishRjsfSchemaV1Beta2` / `CatalogPublishRjsfUiSchemaV1Beta2` from its top-level index. Coordinate the dep bump (and this branch's merge) with that release. Branch is intentionally left local pending that publication. Signed-off-by: Yi Nuo <218099172+yi-nuo426@users.noreply.github.com>
@meshery/schemas v1.2.8 ships the canonical RJSF form schemas under schemas/constructs/<v>/<c>/forms/, exported from the package as e.g. CatalogPublishRjsfSchemaV1Beta2. Pairs with the prior commit on this branch (9c0e709) which flipped publishCatalogItem to re-export from @meshery/schemas. With v1.2.7 that re-export failed at TS compile time (the canonical export didn't exist yet); v1.2.8 makes it resolve cleanly. The remaining 9 forms in src/schemas/ still carry TODO headers referencing meshery/schemas#866 — they ship as canonical schemas land upstream (deferred forms tracked in meshery/schemas#868 and #869), at which point each gets the same flip. Verified -------- - npm test: 11 suites / 29 tests pass. - npm run build: tsup + dts builds green. - node -e "require('@meshery/schemas').CatalogPublishRjsfSchemaV1Beta2" resolves to a valid object with the 4 expected fields (compatibility, patternCaveats, patternInfo, type). - npx tsc --noEmit: src/schemas/ is clean. (Errors elsewhere in examples/next-16/lib/palette.ts and src/__testing__/*.test.tsx are pre-existing on master and unrelated.) Signed-off-by: Yi Nuo <218099172+yi-nuo426@users.noreply.github.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request updates the package version to 0.22.0 and upgrades the @meshery/schemas dependency to version 1.2.8. It initiates the migration of form schemas to a centralized source by replacing local definitions for publishCatalogItem with re-exports from @meshery/schemas. Furthermore, it adds TODO documentation to various other schema files to coordinate future migration phases. I have no feedback to provide.
…ase 3) Extends this PR (per maintainer request) to flip every Sistent form whose canonical export now ships in @meshery/schemas v1.2.8. The remaining 4 forms (importDesign, importFilter, importModel, helmConnection) stay TODO-headed pending meshery/schemas#868 and #869 — those have canonical-side gaps still being resolved. Forms flipped in this commit ---------------------------- src/schemas/createAndEditEnvironment/ EnvironmentCreateOrEditRjsfSchemaV1Beta3 src/schemas/createAndEditWorkspace/ WorkspaceCreateOrEditRjsfSchemaV1Beta3 (default) + locally-derived editWorkspace (relaxed required) src/schemas/kubernetesCredential/ KubernetesCredentialRjsfSchemaV1Beta1 src/schemas/grafanaCredential/ GrafanaCredentialRjsfSchemaV1Beta1 src/schemas/prometheusCredential/ PrometheusCredentialRjsfSchemaV1Beta1 For each: schema.tsx and uiSchema.tsx are both flipped to re-exports. The published Sistent export names (createAndEditEnvironmentSchema, kubernetesCredentialSchema, etc.) are unchanged. Wire-level changes ------------------ The canonical schemas use canonical field names; the hand-authored Sistent forms didn't. Submission payloads from the flipped forms now use: - `organizationId` instead of `organization` (env, workspace). Matches WorkspacePayload.organizationId / EnvironmentPayload.organizationId in @meshery/schemas. The Meshery server's endpoints already accept the canonical key per their OpenAPI; this aligns the form payload. - `name` instead of `credentialName` (k8s, grafana, prometheus). Matches Credential.name. Same alignment story. Consumers in `meshery` and `meshery-cloud` keep working without source-level changes (the Sistent export names didn't move) but the shape of the data they POST changes for these specific forms. editWorkspace derivation ------------------------ Sistent ships a relaxed-required `editWorkspace` named export alongside the default create-or-edit schema. v1.2.8 only ships the strict variant (`WorkspaceCreateOrEditRjsfSchemaV1Beta3`); the edit-only relaxation isn't canonicalized yet. So this commit derives `editWorkspace` locally by spreading the canonical and overriding `required: ['organizationId']`. The derived const is intentionally typed `Record<string, unknown>` because @meshery/schemas declares `RJSFSchema` internally but does NOT yet re-export it — tsup's DTS bundler errors out when the emitted .d.ts references the un-exportable type. Filed meshery/schemas#871 to add `export type { RJSFSchema, UiSchema }` upstream; once that lands the annotation can be tightened. Verified -------- - `npm test`: 11 suites / 29 tests pass. - `npx tsc --noEmit`: src/schemas/ is clean. Pre-existing errors in examples/next-16/lib/palette.ts and src/__testing__/*.test.tsx are on master and unrelated. - `npm run build`: tsup ESM/CJS + DTS all green. dts/index.d.ts size dropped from 95.89 KB to 91.66 KB (the re-exports are smaller than the hand-authored object literals they replaced). - Runtime: `require('@meshery/schemas')` resolves all 6 canonical exports to valid objects with the expected required fields: Catalog: [compatibility, patternCaveats, patternInfo, type] Environment: [name] Workspace: [name, organizationId] *Credential: [name] Signed-off-by: Yi Nuo <218099172+yi-nuo426@users.noreply.github.com>
leecalcote
changed the title
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.
Summary
Phase 3 of meshery/schemas#866. Flips 6 Sistent form schemas from hand-authored object literals to re-exports of canonical artifacts in
@meshery/schemasv1.2.8. The Sistent-published export names are unchanged so all downstream consumers (meshery, meshery-cloud) keep working without source-level changes.Forms flipped
publishCatalogItemCatalogPublishRjsfSchemaV1Beta2/…UiSchema…createAndEditEnvironmentEnvironmentCreateOrEditRjsfSchemaV1Beta3/…UiSchema…createAndEditWorkspace(default)WorkspaceCreateOrEditRjsfSchemaV1Beta3/…UiSchema…editWorkspace(named){ ...canonical, required: ['organizationId'] }(see below)kubernetesCredentialKubernetesCredentialRjsfSchemaV1Beta1/…UiSchema…grafanaCredentialGrafanaCredentialRjsfSchemaV1Beta1/…UiSchema…prometheusCredentialPrometheusCredentialRjsfSchemaV1Beta1/…UiSchema…Wire-level changes
The canonical form schemas use canonical field names; the hand-authored Sistent forms didn't. Submission payloads from the flipped forms now use:
organizationIdinstead oforganization(environment, workspace) — matchesWorkspacePayload.organizationId/EnvironmentPayload.organizationIdnameinstead ofcredentialName(kubernetes, grafana, prometheus) — matchesCredential.nameThe Meshery server's Environment / Workspace / Credential endpoints already accept the canonical keys per their OpenAPI; this brings the form payloads into alignment.
editWorkspacederivationSistent ships a relaxed-required
editWorkspacenamed export alongside the default create-or-edit schema. v1.2.8 only ships the strict variant; the edit-only relaxation isn't canonicalized yet. This PR deriveseditWorkspacelocally by spreading the canonical and overridingrequired: ['organizationId']. Once@meshery/schemasships anWorkspaceEditRjsfSchemaV1Beta3(per the #866 roadmap), the derivation can be replaced with a direct re-export.The derived const is intentionally typed
Record<string, unknown>because@meshery/schemasdeclaresRJSFSchemainternally but doesn't yet re-export it as a public type — tsup's DTS bundler errors out when the emitted.d.tsreferences the un-exportable type. Filed meshery/schemas#871 to add the type export upstream; once that lands, the annotation can be tightened.Pending (out of scope here)
These 4 forms still carry TODO headers pointing at #866 and stay hand-authored until the canonical-side gaps are resolved:
importDesign,importFilter,importModel— pending meshery/schemas#868 (uploadTypediscriminator vs canonicaloneOfshape)helmConnection— pending meshery/schemas#869 (canonical Connection puts kind-specific fields undermetadata, not top-level)helpAndSupportModalstays Sistent-local — UI-only, no canonical construct.Bumps
@meshery/schemas:^1.2.7→^1.2.8. v1.2.8 ships the canonical form-schema exports.@sistent/sistentpackage version:0.21.0→0.22.0. The public-export names are unchanged but the underlying schema source moves repos AND the wire-level field names change for several forms — that's a more significant semantic shift than a typical patch, so a minor bump is appropriate.Test plan
npm install— bumps@meshery/schemasto 1.2.8 cleanlynpm test— 11 suites / 29 tests passnpm run build— tsup ESM/CJS + DTS green;dist/index.d.tssize drops from 95.89 KB to 91.66 KB (the re-exports are smaller than the hand-authored object literals they replaced)require('@meshery/schemas')gives valid objects with the expectedrequiredfields:- Catalog:
[compatibility, patternCaveats, patternInfo, type]- Environment:
[name]- Workspace:
[name, organizationId](canonical key, notorganization)- Each
*Credential:[name](canonical key, notcredentialName)npx tsc --noEmit:src/schemas/is clean. Pre-existing errors inexamples/next-16/lib/palette.tsandsrc/__testing__/*.test.tsxare unrelated and present on master.mesheryandmeshery-cloudafter a@sistent/sistent@0.22.0bump in those repos. The Integration Test with Meshery UI on this PR exercises the catalog publish path end-to-end and was green on the first commit.Refs: meshery/schemas#866, meshery/schemas#867, meshery/schemas#871.