chore: centralize react/react-dom/@types/react in pnpm catalog#624
Merged
Conversation
The react peer ranges were already aligned across the library packages (react `^18.3.1 || ^19.0.0`, react-dom `^18.0.0 || ^19.0.0`) but declared inline in each package, and @types/react was split across three ranges (`^19.0.0`, `^19`, `>=19.0.0`). Add react, react-dom and @types/react to the catalog and reference them via the catalog: protocol from react-lang, react-ui, react-headless and react-email. @types/react is unified to `>=19.0.0`. browser-bundle's react/react-dom stay explicit: they are runtime dependencies pinned to `^19.0.0` (the bundled version), not the wider peer range, so they intentionally don't share the catalog entry. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
f1cb652 to
8160b8b
Compare
ankit-thesys
approved these changes
Jun 10, 2026
ankit-thesys
left a comment
Contributor
There was a problem hiding this comment.
Looks Good.
Thank you for your contribution :)
4 tasks
ankit-thesys
pushed a commit
that referenced
this pull request
Jun 12, 2026
* chore: centralize typescript version with pnpm catalog typescript was declared as a devDependency with divergent specs across the library packages and the monorepo root (`^5.9.3`, `^5`, `^5.0.0`). Move the version into the pnpm catalog and reference it via the "catalog:" protocol so the toolchain version lives in one place, mirroring #612/#624/#634. Cataloged spec: `^5.9.3` (the root's existing spec). - package.json `^5.9.3` -> catalog: - packages/react-email `^5` -> catalog: - packages/svelte-lang `^5.0.0` -> catalog: - packages/vue-lang `^5.0.0` -> catalog: No resolved-version change: every importer already resolved to typescript@5.9.3, so this only tightens the declared specs onto the single catalog entry. examples/ and docs/ keep their inline `^5`/`~5.9.2` specs, matching #612's library-only scope. Verified: react-email/svelte-lang/vue-lang build + typecheck pass with typescript 5.9.3 resolved from the catalog. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(svelte-lang): use bracket access for index-signature lookups in test `svelte-check` failed on src/__tests__/library.test.ts: the root tsconfig enables `noPropertyAccessFromIndexSignature`, and `lib.components` carries a string index signature, so dot access (`lib.components.TextContent`) is rejected. The parallel vue-lang test already uses bracket access; bring svelte-lang in line. Pre-existing on main, surfaced while verifying the catalog change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2 tasks
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
Follow-up to the pnpm catalog work (#612). Centralizes the React-related dependencies through the
catalog:protocol so their versions live in one place.The
react/react-dompeer ranges were already aligned across the library packages but declared inline in eachpackage.json, and@types/reactwas split across three equivalent-but-different ranges.Changes
Added to the
cataloginpnpm-workspace.yaml:react^18.3.1 || ^19.0.0react-dom^18.0.0 || ^19.0.0@types/react>=19.0.0Replaced the inline versions with
catalog:in:react-lang—react(peer),@types/react(^19.0.0→ catalog)react-ui—react,react-dom(peer),@types/react(>=19.0.0→ catalog)react-headless—react(peer),@types/react(>=19.0.0→ catalog)react-email—react,react-dom(peer),@types/react(^19→ catalog)@types/reactis unified to>=19.0.0(matchingreact-ui/react-headless).Intentionally left as-is
browser-bundlereact/react-domare runtimedependenciespinned to^19.0.0(the bundled version), not the wider peer range — they shouldn't share the peer catalog entry.@types/react-domis used in a single package, so there's no version to centralize.openui-clichat template is outside the workspace (!**/src/templates/**), socatalog:would not resolve there.Verification
pnpm installresolves cleanly (remaining peer warnings are pre-existing and unrelated)@openuidev/react-headlesstests: 70 passed / 70react-lang/react-uihave no test files (--passWithNoTests)🤖 Generated with Claude Code