fix(schemas): align importDesign with oneOf[File|URL] shape (0.19.1)

[miacycle]

Summary

Fixes the Next.js SSR crash TypeError: Cannot read properties of undefined (reading 'name') that surfaced downstream in meshery-cloud staging after pinning @sistent/sistent@0.19.0 (meshery-cloud PR #5094) and that was also flagged on PRs #1431 / #1433 but deferred as "out of scope."

Root cause

meshery/schemas commit b08a4f62 tightened MesheryPatternImportRequestBody from a flat properties object to a oneOf: [MesheryPatternImportFilePayload, MesheryPatternImportURLPayload] union, matching the server handler's "exactly one of File Import or URL Import" contract. That contract shipped in @meshery/schemas@1.1.0 and is re-exposed here through the bundled DesignDefinitionV1Beta1OpenApiSchema.

src/schemas/importDesign/schema.tsx still walked .properties.name, .properties.file, .properties.url at the root of the request body. With the oneOf shape those paths resolve to undefined, and module evaluation throws at the first .properties.name.type read — before any React component even mounts. Because Sistent bundles @meshery/schemas inline (noExternal: [/^@meshery\\/schemas/] in tsup.config.ts), every downstream Next.js SSR build ships the same crash at Collecting page data.

Fix

Resolve the individual field shapes from the dedicated payload components so the UI schema continues to be driven by the API contract rather than duplicating it:

• name and file come from MesheryPatternImportFilePayload.properties
• url comes from MesheryPatternImportURLPayload.properties
• The top-level prompt description still sources from the wrapper MesheryPatternImportRequestBody.description

No behavior change for the rendered form — same fields, same descriptions, same validation.

Version bump

Bumps to 0.19.1. Downstream consumers pinned ^0.19.0 (meshery-cloud, meshery-ui, meshery-extensions) will pick this up on their next install without any consumer-side change.

Test plan

• npm run build succeeds (tsup produces dist/index.js and dist/index.mjs).
• npm test passes (7 suites / 21 tests).
• require('@sistent/sistent') no longer throws at module load.
• meshery-cloud/ui npm run build-staging completes successfully with the patched sistent overlaid into node_modules/ (previously crashed at Collecting page data using 7 workers).
• importDesignSchema resolves to a well-formed JSON schema with properties.name.title === 'Design file name'.

[gemini-code-assist]

Code Review

This pull request updates the package version to 0.19.1 and refactors the importDesignSchema to accommodate structural changes in the upstream @meshery/schemas library, specifically handling the transition of the import request body to a oneOf union. Feedback was provided to use optional chaining and default fallback objects when extracting schema properties to ensure module safety and prevent potential runtime errors or SSR crashes if the schema structure is unexpected.

[gemini-code-assist]

While this change correctly identifies the new location of the properties in the updated schema, the property access remains unsafe at the module level. If FilePayload or URLPayload are missing or their properties are undefined, the module will still throw a TypeError during evaluation, which causes SSR crashes in Next.js (the exact issue this PR aims to fix). Using optional chaining and providing fallback objects ensures the module can load safely even if the upstream schema structure is unexpected or partially loaded.

Suggested change

	const ImportBody = DesignSchema.MesheryPatternImportRequestBody;
	const FilePayload = DesignSchema.MesheryPatternImportFilePayload;
	const URLPayload = DesignSchema.MesheryPatternImportURLPayload;
	// `name` is a common field present on both variants; File is used as the
	// canonical source.
	const nameField = FilePayload.properties.name;
	const fileField = FilePayload.properties.file;
	const urlField = URLPayload.properties.url;
	const ImportBody = DesignSchema?.MesheryPatternImportRequestBody || {};
	const FilePayload = DesignSchema?.MesheryPatternImportFilePayload || {};
	const URLPayload = DesignSchema?.MesheryPatternImportURLPayload || {};
	// `name` is a common field present on both variants; File is used as the
	// canonical source.
	const nameField = FilePayload.properties?.name || {};
	const fileField = FilePayload.properties?.file || {};
	const urlField = URLPayload.properties?.url || {};

[leecalcote]

Fixes the 0.19.0 SSR crash at module load (MesheryPatternImportRequestBody.properties undefined under the oneOf contract). Verified locally by overlaying the rebuilt tarball into meshery-cloud/ui and running the staging build end-to-end — passes Collecting page data and onward. Merging to cut v0.19.1.

[Copilot]

Pull request overview

Updates Sistent’s importDesign JSON schema generation to match the upstream @meshery/schemas change where MesheryPatternImportRequestBody is now a oneOf union (file vs URL payload), preventing a Next.js SSR crash caused by reading nested properties.* from an incompatible shape.

Changes:

• Resolve name, file, and url field definitions from MesheryPatternImportFilePayload / MesheryPatternImportURLPayload instead of MesheryPatternImportRequestBody.properties.*.
• Keep the top-level description sourced from MesheryPatternImportRequestBody.description.
• Bump package version to 0.19.1 (and lockfile version metadata accordingly).

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File	Description
src/schemas/importDesign/schema.tsx	Fixes schema field lookups to align with the upstream oneOf request-body shape and avoid SSR-time undefined property access.
package.json	Version bump to 0.19.1 for the patch release.
package-lock.json	Lockfile metadata updated to 0.19.1.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.