Add @rushstack/heft-zod-schema-plugin and pilot it on rush-lib's experiments.json#5788
Add @rushstack/heft-zod-schema-plugin and pilot it on rush-lib's experiments.json#5788
Conversation
…om zod validators Agent-Logs-Url: https://github.com/microsoft/rushstack/sessions/f6417dd3-99b5-4eb5-9343-ecf5de6c37c4 Co-authored-by: iclanton <5010588+iclanton@users.noreply.github.com>
Agent-Logs-Url: https://github.com/microsoft/rushstack/sessions/f6417dd3-99b5-4eb5-9343-ecf5de6c37c4 Co-authored-by: iclanton <5010588+iclanton@users.noreply.github.com>
Agent-Logs-Url: https://github.com/microsoft/rushstack/sessions/f6417dd3-99b5-4eb5-9343-ecf5de6c37c4 Co-authored-by: iclanton <5010588+iclanton@users.noreply.github.com>
Agent-Logs-Url: https://github.com/microsoft/rushstack/sessions/b7297c08-8212-4a0e-b5fa-f4d4ff39a8db Co-authored-by: iclanton <5010588+iclanton@users.noreply.github.com>
…c; fix shold→should typo Agent-Logs-Url: https://github.com/microsoft/rushstack/sessions/b7297c08-8212-4a0e-b5fa-f4d4ff39a8db Co-authored-by: iclanton <5010588+iclanton@users.noreply.github.com>
iclanton
left a comment
There was a problem hiding this comment.
@copilot - next steps:
- Make use of the other ported schemas in rush-lib
- Replace the .schema.json files in rush-lib's output with the ones from the schemas project
- Use zod to validate the loaded objects instead of
JsonSchema - Consider adding support for
zodschemas innode-core-library'sJsonFile.
| "name": "@reduxjs/toolkit", | ||
| "allowedCategories": [ "libraries", "vscode-extensions" ] | ||
| }, | ||
| { |
| // rush-mcp-server pins to zod 3 to remain compatible with @modelcontextprotocol/sdk; | ||
| // heft-zod-schema-plugin and the rush-lib pilot use zod 4 for its built-in | ||
| // z.toJSONSchema() API. | ||
| "~3.25.76" |
There was a problem hiding this comment.
@copilot - can we upgrade @modelcontextprotocol/sdk to pull in v4 of zod in the project that currently needs v3?
There was a problem hiding this comment.
Latest @modelcontextprotocol/sdk (1.25+/1.29) does support zod ^3.25 || ^4.0, so in principle yes. I tried the upgrade locally and it surfaces two unrelated breaks that need real source changes in rush-mcp-server:
apps/rush-mcp-server/src/tools/base.tool.tsusesz.objectOutputType<...>— that's a zod-3 internal type that was removed in zod 4; theBaseToolgeneric plumbing needs to be re-expressed.- The newer SDK pulls in a transitive
transport.d.tsthat references the DOMHeadersInitglobal, which doesn't resolve under the current@types/node/libsettings.
Neither is conceptually hard, but both are out-of-scope for this PR (which is the schemas package pivot) and want their own validation. Reverted the speculative upgrade in this branch and left a follow-up task in the PR description so the zod-3 alternative version stays scoped to rush-mcp-server for now.
| it('emits a JSON schema for a basic zod default export', async () => { | ||
| const generator: ZodSchemaGenerator = new ZodSchemaGenerator({ | ||
| buildFolderPath: projectFolder, | ||
| inputGlobs: [path.relative(projectFolder, path.join(compiledFixturesFolder, 'basic.zod.js'))], |
There was a problem hiding this comment.
@copilot - Seems like inputGlobs should be able to accept absolute paths. Also, just use template strings with /s.
Same in other places in this file.
There was a problem hiding this comment.
Switched the test to template strings with / and absolute paths in 60d69b0. Also hardened ZodSchemaGenerator itself: inputGlobs are now run through Path.convertToSlashes() (so absolute/Windows-style paths reach fast-glob in its required form), and outputFolder is resolved with path.resolve() instead of path.join() so an absolute value works as expected.
| "extends": "./node_modules/local-node-rig/profiles/default/tsconfig-base.json", | ||
|
|
||
| "compilerOptions": { | ||
| "target": "ES2019" |
There was a problem hiding this comment.
No good reason — leftover from copying another project's tsconfig. The rig already sets a sensible target. Removed the override in 60d69b0.
| "projectFolder": "libraries/rush-schemas", | ||
| "reviewCategory": "libraries", | ||
| "shouldPublish": true | ||
| }, |
There was a problem hiding this comment.
This should be in the Rush version policy.
There was a problem hiding this comment.
Switched to "versionPolicyName": "rush" in 60d69b0.
| */ | ||
| export type IRepoStateJson = Omit<z.infer<typeof repoStateSchema>, '$schema'>; | ||
|
|
||
| export default repoStateSchema; |
There was a problem hiding this comment.
Removed the IRepoStateJson type alias (and its index.ts re-export) in 60d69b0. rush-lib's RepoStateFile.ts already keeps its own internal interface, and nothing else consumes it.
| "pnpm-sync-lib": "0.3.3", | ||
| "read-package-tree": "~5.1.5", | ||
| "rxjs": "~6.6.7", | ||
| "@rushstack/rush-schemas": "workspace:*", |
| // See LICENSE in the project root for license information. | ||
|
|
||
| import { JsonFile, JsonSchema, FileSystem } from '@rushstack/node-core-library'; | ||
| import type { IExperimentsJson } from '@rushstack/rush-schemas/lib/experiments.zod'; |
There was a problem hiding this comment.
@copilot - import this from the entrypoint of the package.
There was a problem hiding this comment.
Switched to import type { IExperimentsJson } from '@rushstack/rush-schemas' in 60d69b0. The API report now records the entrypoint instead of the subpath. While verifying this I also surfaced that rush-sdk's bundled dist/rush-lib.d.ts re-exports the type but didn't list @rushstack/rush-schemas as a dep — added it in 08e3937 so downstream consumers of rush-sdk resolve cleanly.
…oStateJson, package entrypoint imports Agent-Logs-Url: https://github.com/microsoft/rushstack/sessions/83bb9e28-6062-4265-851a-ce82c95398ec Co-authored-by: iclanton <5010588+iclanton@users.noreply.github.com>
…ntsJson re-export resolves Agent-Logs-Url: https://github.com/microsoft/rushstack/sessions/83bb9e28-6062-4265-851a-ce82c95398ec Co-authored-by: iclanton <5010588+iclanton@users.noreply.github.com>
Acknowledged — these four are clearly the right next steps but each is a meaningful, independently-validatable change, so I'd like to take them as a follow-up PR (or a small series) rather than fold them into this one. Quick sketch of how I'd approach each:
Happy to open the first one of these when you're ready. |
Address review feedback on the prior pivot to
@rushstack/rush-schemas.@rushstack/heft-zod-schema-pluginand@rushstack/rush-schemasfrombrowser-approved-packages.jsontononbrowser-approved-packages.jsonCHANGELOG.json/CHANGELOG.mdin both new packages (autogenerated at publish)target: "ES2019"override inlibraries/rush-schemas/tsconfig.json@rushstack/rush-schemasunder therushversion policy inrush.jsonIRepoStateJsontype alias fromrepo-state.zod.ts(rush-lib has its own internal interface)@rushstack/rush-schemasto its alphabetical position inlibraries/rush-lib/package.json's dependenciesIExperimentsJsonfrom the package entrypoint (@rushstack/rush-schemas)/s and pass absolute paths inZodSchemaGenerator.test.ts; harden the generator to accept absolute paths in bothinputGlobsandoutputFolder@rushstack/rush-schemasas a dependency of rush-sdk so its bundleddist/rush-lib.d.ts(which re-exportsIExperimentsJson) resolves for downstream consumers