Add BYO zod version support

[fredericbarthelet]

Following fix implementation from @matteo8p in #42 , I suggest directly requiring zod v4 in package.json rather than relying on v4 being exported from v3.

Motivation and Context

zod subpath import allows easier migration. Since the previous PR solves npm i, you can now finish migration with a final update of zod versions

How Has This Been Tested?

running npm i & npm start on a fresh install of the project and check that it renders correctly on localhost:8080

Breaking Changes

major upgrade in package.json, but was already up in previous PR #42

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally (no test on the repo)
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[ochafik]

@jonathanhefner adding you as reviewer in case you know more about implications of zod v3 vs v4 :-)

[jonathanhefner]

adding you as reviewer in case you know more about implications of zod v3 vs v4 :-)

We are actually using v4 currently, but we are importing it from the v3 package, which Zod supports since v3.25+ to ease migration.

Actually though, I'm more inclined to match what the MCP TypeScript SDK currently does, which should allow users to "bring their own Zod". In our case, it wouldn't benefit the API (the schema objects would still just use zod/v4), but it might avoid loading another package into memory.

@fredericbarthelet Do you see any drawbacks of that approach?

[fredericbarthelet]

Thanks for your feedbacks @ochafik@jonathanhefner
You're right. It's much better to provide flexibility on zod majors and implement a BYO zod pattern.
I followed recommendations from zod listed in https://zod.dev/library-authors

I did locked zod v4 in the exemple implementation in simple-server though, as would a developer in a brand new project.

One of the main difference with TS SDK implementation is not putting zod as a dependency, but rather as a dev dependency.

Just so you know and you don't get surprised by the amount of line changed in this PR. Adding a peer dependency in the project for the first time resulted in the following error:

Error: Cannot find module @rollup/rollup-darwin-arm64. npm has a bug related to optional dependencies (npm/cli#4828). Please try npm i again after removing both package-lock.json and node_modules directory.

Regenerating a new package-lock.json as instructed solved the issue. I figured this wouldn't be a problem given the fact that this file got versioned in the repo less than a day ago.

Let me know if you'd want me to change anything to the implementation.

[fredericbarthelet]

You fixed the npm/cli error with #73
I'll rebase to resolve conflicts. Let me know if everything's ok to merge now :)

[fredericbarthelet]

Hey @jonathanhefner, just rebased this PR on top of the latest implementation of exemple apps you made :)
Is it good to go in its current shape? Thanks :)!

[fredericbarthelet]

Hey @ochafik@jonathanhefner, sorry for the ping. Just made another update to resolve conflicts that appeared since my last push. Would you like me to change anything in the implementation ?
Thanks !

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/modelcontextprotocol/ext-apps/@modelcontextprotocol/ext-apps@49

commit: e99517d

[jonathanhefner]

Thank you, @fredericbarthelet!