chore: add pnpm catalog dependencies to centralize version management #2294
Conversation
|
Summary of ChangesHello @danielleroux, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request streamlines dependency management within the monorepo by adopting pnpm's catalog feature. This change centralizes the definition of versions for critical development dependencies such as Playwright, Vite, and Esbuild, ensuring consistency and simplifying future updates across all packages. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces pnpm catalogs to centralize dependency version management, which is a commendable improvement for maintaining this monorepo. The changes correctly implement the catalog for dependencies like @playwright/test and @esbuild/linux-arm64.
However, this PR also includes a significant major version upgrade for vite across multiple packages (e.g., from v4 to v7), which is a substantial change not reflected in the chore scope of the PR. This carries a risk of introducing breaking changes. My review includes a comment with suggestions on how to handle this.
| - 'testing/*' | ||
|
|
||
| catalog: | ||
| vite: ^7.2.6 |
There was a problem hiding this comment.
This change centralizes the vite version, which is great. However, it also upgrades vite from v4 and v6 to v7 for several packages. This is a major version bump that could introduce breaking changes.
For example:
packages/html-test-appmoves from^4.5.14to^7.2.6.packages/aggridmoves from^6.3.5to^7.2.6.
A chore pull request should ideally not contain potentially breaking changes. Could you please clarify if this upgrade was intentional and if the affected applications have been thoroughly tested?
If the upgrade is intentional, it would be better to change the PR title to reflect this (e.g., feat: upgrade vite to v7 and centralize versions) and add more details about the upgrade in the description.
Alternatively, you could consider keeping the vite versions as they are for now by defining multiple versions in the catalog or keeping them in package.json files, and handle the upgrade in a separate PR.
🆕 What is the new behavior?
This branch introduces pnpm catalog dependencies to centralize version management across the IX monorepo.
🏁 Checklist
A pull request can only be merged if all of these conditions are met (where applicable):
pnpm test)pnpm lint)pnpm build, changes pushed)👨💻 Help & support