Studio: Update zod to v4

[katinthehatsite]

Related issues

Fixes STU-517

Proposed Changes

This PR updates to Zod v4 and resolves incompatibility issues.

Testing Instructions

• Confirm that all the checks pass (I also triggered builds for this just in case and everything went through)
• Visual review should suffice
• Additionally, pull the changes from this branch, start the app with npm start, test the app holistically, especially around actions that make API requests, and confirm there are no errors in the console

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[katinthehatsite]

For reference on changes: https://zod.dev/v4/changelog (if you want to double-check things)

[wpmobilebot]

📊 Performance Test Results

Comparing 266f4b3 vs trunk

site-editor

Metric	trunk	266f4b3	Diff	Change
load	2924.00 ms	2936.00 ms	+12.00 ms	🔴 0.4%

site-startup

Metric	trunk	266f4b3	Diff	Change
siteCreation	8103.00 ms	8070.00 ms	-33.00 ms	🟢 -0.4%
siteStartup	3948.00 ms	3936.00 ms	-12.00 ms	🟢 -0.3%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change

[epeicher]

Thanks for upgrading this, Kat! I’ve done a smoke test on some parts of the application and haven’t found any issues, including nothing in the DevTools console.

I’ve left a comment about one change required for the new version, which should also fix the unit tests. Once that’s updated, this should be good to go.

[ivan-ottinger]

For reference on changes: https://zod.dev/v4/changelog (if you want to double-check things)

Thanks for linking the changelog link, Kat!

I have noticed that we may also want to update the .merge in cli/lib/types/wordpress-server-ipc.ts:

@@ -44,9 +44,9 @@ export type ManagerMessagePayload = z.infer< typeof _managerMessagePayloadSchem
 
 const managerMessageBase = z.object( { messageId: z.number() } );
 export const managerMessageSchema = z.discriminatedUnion( 'topic', [
-	managerMessageBase.merge( managerMessageStartServer ),
-	managerMessageBase.merge( managerMessageRunBlueprint ),
-	managerMessageBase.merge( managerMessageStopServer ),
+	managerMessageBase.extend( managerMessageStartServer.shape ),
+	managerMessageBase.extend( managerMessageRunBlueprint.shape ),
+	managerMessageBase.extend( managerMessageStopServer.shape ),
 ] );
 export type ManagerMessage = z.infer< typeof managerMessageSchema >;

also the following change in src/stores/wpcom-api.ts:

@@ -119,7 +119,7 @@ const wpcomPublicBaseQuery: BaseQueryFn<
 	}
 };
 
-function parseResponse< TSchema extends z.ZodTypeAny >(
+function parseResponse< TSchema extends z.ZodType >(
 	response: unknown,
 	schema: TSchema
 ): z.infer< TSchema > {

[katinthehatsite]

I have noticed that we may also want to update the .merge in cli/lib/types/wordpress-server-ipc.ts:

I applied your suggestions in 6848bf1 - please let me know what you think 🙇

[ivan-ottinger]

I applied your suggestions in 6848bf1 - please let me know what you think 🙇

Looks good! Thanks for the update, Kat. I did not observe any other changes that would be missing.

[fredrikekelund]

@katinthehatsite, how come the StatsMetric enum isn't included in the new schema?

[katinthehatsite]

I think it was mostly something that I overlooked during the update. I added a follow-up PR here: #2417 . I also noticed that there were more updates needed after the CLI dev branch was merged so I addressed these changes there as well.

[katinthehatsite]

Actually I looked into it a bit more and ended up removing them even in the follow-up PR. Initially, I kept them but it required more code that seemed unnecessary. I think it is okay to remove it, and it feels like a more pragmatic choice. TypeScript already enforces type safety at compile-time where the data is created. Zod will validate the data structure (nested records with numbers) in this case and does not necessarily need to duplicate TypeScript's business logic validation of enum values.

[fredrikekelund]

See #2417 (comment)

[katinthehatsite]

I tried that option 😅 but ultimately, it did not seem to be the best one. I added some details here: #2417 (comment)