[WEB-4809] chore: added common libs to pnpm workspace catalog#7611
[WEB-4809] chore: added common libs to pnpm workspace catalog#7611sriramveeraghanta merged 8 commits intopreviewfrom
Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughReplace many explicit package version pins with pnpm catalog aliases across apps and packages; add a root-level catalog block in pnpm-workspace.yaml and set TypeScript override to Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer / CI
participant PNPM as pnpm
participant WS as Workspace (pnpm-workspace.yaml)
participant PKG as package.json(s)
Dev->>PNPM: install / build
PNPM->>WS: read workspace + catalog block
WS-->>PNPM: provide centralized versions (catalog)
PNPM->>PKG: resolve `catalog:` aliases
PKG-->>PNPM: resolved package versions
PNPM->>Dev: install artifacts
note right of WS #D6EAF8: New centralized catalog\ndrives version resolution
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (11)
packages/logger/package.json (1)
40-42: Optional: Consider moving esbuild override into the catalog for full centralization.
Not required for this PR, but it avoids mixing direct overrides and catalog pins.Proposed diff in root package.json (only if you add an esbuild entry to the catalog):
"pnpm": { "overrides": { - "esbuild": "0.25.0", + "esbuild": "catalog:",packages/propel/package.json (1)
50-55: Match @types/react to the React major pinned in the catalog.*If the catalog pins React 18, ensure @types/react and @types/react-dom are also 18.x to avoid TS friction (e.g., useId/use/transition types changed in 19). If you intend to move to React 19 later, plan a coordinated bump across Storybook and all @types/*.
As a safety net, consider adding a brief constraint comment near the catalog pins in pnpm-workspace.yaml noting "React 18 required until Next/Storybook upgrades complete."
apps/web/package.json (1)
77-83: Types and TS moved to catalog—consider aligning @types/node as well.This keeps TS and React types consistent. In the same spirit, consider migrating "@types/node": "18.16.1" to catalog to avoid divergent Node type baselines across packages (several packages use ^22.x). If you agree, add @types/node to the workspace catalog and flip this package to "catalog:".
Proposed follow-up diffs:
pnpm-workspace.yaml
catalog: react: 18.3.1 react-dom: 18.3.1 "@types/react": 18.3.1 "@types/react-dom": 18.3.1 typescript: 5.8.3 tsup: 8.4.0 + "@types/node": 22.5.4apps/web/package.json
"devDependencies": { "@plane/eslint-config": "workspace:*", "@plane/tailwind-config": "workspace:*", "@plane/typescript-config": "workspace:*", "@types/lodash": "^4.17.6", - "@types/node": "18.16.1", + "@types/node": "catalog:", "@types/react": "catalog:",packages/types/package.json (1)
30-31: Using catalog in peerDependencies: fine for private packages; reconsider if publishing.Since this package is "private": true, using catalog in peerDependencies is OK. If you ever plan to publish it, prefer a semver range (e.g., "^18.0.0") to avoid leaking workspace internals to consumers.
packages/utils/package.json (1)
41-45: Dev types and build tools via catalog—LGTM; consider cataloging @types/node repo-wide.Echoing web app feedback: adding @types/node to the catalog will eliminate the current split between 18.x and 22.x across packages.
packages/i18n/package.json (2)
29-31: Good move to centralize @types/react and typescript via the catalog.This aligns the package with the workspace-wide version management. No functional risk here since both are dev-only.
- Consider adding "@types/node" to the catalog as well to avoid drift across packages (this repo has multiple distinct @types/node pins).
Covered by the verification script I added in apps/admin/package.json to check catalog keys and cross-package consistency.
32-32: Nit: trailing change on the closing brace.Looks like a formatting-only change. If this wasn’t intentional, you can skip touching the trailing newline/brace to keep diffs minimal.
apps/admin/package.json (1)
50-54: Typescript override in root package.json correctly points to “catalog:”I’ve verified that your root package.json’s pnpm.overrides includes:
"typescript": "catalog:"This matches the catalog pin in apps/admin/package.json, so there’s a single source of truth and no conflicting version overrides.
Optional next step:
- Consider removing the explicit typescript override if you don’t need to force transitive dependencies to that exact version. [optional]
packages/ui/package.json (1)
28-29: PeerDependencies “catalog:” usage is safe while privateAll instances of
peerDependenciesreferencing"catalog:"are confined to private packages, so there’s no risk of non-standard version ranges leaking to npm/yarn consumers:
packages/editor/package.json(private: true)packages/types/package.json(private: true)packages/ui/package.json(private: true)• No non-private package uses
"catalog:"inpeerDependencies.
• Since each package is marked"private": true, the current setup is acceptable.Optional suggestion: if you later publish any of these packages publicly, update their
peerDependenciesto a proper semver range (e.g.^18) and retain"catalog:"only in runtime dependencies to centralize version management.packages/editor/package.json (2)
35-36: Peer deps on React via catalog mirror the UI package—private status makes this safe.Same caveat: if this package is ever published, consumers outside your workspace might not resolve "catalog:". Keep it while private.
If publication is planned later, prefer semver ranges in peerDependencies.
88-93: Confirmed pnpm version meets catalog support requirementThe root package.json already specifies
"packageManager": "pnpm@10.12.1"which satisfies the requirement for pnpm v9+ and will ensure CI installs pnpm 10.12.1 automatically. No additional version‐check script is necessary.
Remaining recommendations (optional):
- Add a quick consistency check for all
catalog:devDependency entries (e.g. a small lint rule or Node script in CI that scans for"catalog:"specs across package.json files).- Consider defining a Node engine in root package.json to lock the Node.js version, for example:
"engines": { "node": ">=16" }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (19)
apps/admin/package.json(2 hunks)apps/live/package.json(1 hunks)apps/space/package.json(2 hunks)apps/web/package.json(2 hunks)package.json(1 hunks)packages/constants/package.json(1 hunks)packages/decorators/package.json(2 hunks)packages/editor/package.json(3 hunks)packages/eslint-config/package.json(1 hunks)packages/hooks/package.json(1 hunks)packages/i18n/package.json(1 hunks)packages/logger/package.json(1 hunks)packages/propel/package.json(1 hunks)packages/services/package.json(1 hunks)packages/shared-state/package.json(1 hunks)packages/types/package.json(1 hunks)packages/ui/package.json(2 hunks)packages/utils/package.json(2 hunks)pnpm-workspace.yaml(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Build and lint web apps
- GitHub Check: Build and lint web apps
🔇 Additional comments (21)
packages/eslint-config/package.json (1)
21-21: LGTM: Move TypeScript to workspace catalog is consistent with the monorepo migration.
No functional risk here; keeps the config package aligned with central pinning.apps/live/package.json (2)
61-62: LGTM: Centralizing tsup and TypeScript via catalog aligns with the repo-wide change.
No app-level behavior change; keeps toolchain consistent.
61-65: Verify catalog’s tsup ↔ esbuild compatibility
- The root
package.jsonpinsesbuildto0.25.0.- tsup 8.4.0 and later declare
esbuild^0.25.0 in their dependencies, so they’ll accept your override at 0.25.0. (app.unpkg.com)- Older tsup 8.3.x versions list
esbuild^0.24.0, which would not include 0.25.0 and could break your build. (app.unpkg.com)Please confirm that the
catalog:alias for tsup inapps/live/package.jsonresolves to a tsup release ≥ 8.4.0. If it currently targets < 8.4.x, bump it to a version with esbuild ^0.25.0 to ensure compatibility.packages/logger/package.json (1)
40-41: LGTM: Catalog-izing tsup and TypeScript for logger package.
Keeps internal libs on the same toolchain; no runtime impact.package.json (2)
39-39: LGTM: Using catalog for the TypeScript override is the right move.
This enforces a single TS version across all workspaces and transitive deps that declare TS.
39-47: pnpm v10.x supports “catalog:” in overrides
The official pnpm documentation for version 10.x explicitly listsoverridesas a field where thecatalog:protocol can be used, and the v9.6.0 release notes confirm that support forcatalogs:in overrides was added in #8303. You can safely reference catalog entries in yourpnpm.overrideswithout risk of resolution regressions on CI. (pnpm.io, rpm.pbone.net)packages/decorators/package.json (2)
33-34: LGTM: decorators package now follows catalog for toolchain deps.
No API/runtime effect; aligns with workspace policy.
33-35: Sanity sweep complete: all tsup and typescript dependencies use the catalog protocol
No non-catalog references totsuportypescriptwere found in any package.json after the sweep.packages/services/package.json (1)
25-26: pnpm catalog entries and version verifiedBoth required checks have passed:
- pnpm-workspace.yaml defines catalog entries for tsup and typescript.
- Root package.json declares
packageManageras pnpm@10.12.1, which supports catalog dependencies (pnpm 9+).No further changes are needed.
packages/propel/package.json (1)
41-43: Catalog React versions are correctly pinned to 18.3.xThe verification script confirms that pnpm-workspace.yaml pins both react and react-dom to 18.3.1, ensuring the
"catalog:"references in packages/propel/package.json will resolve to React 18.3.x as intended:8: react: 18.3.1 9: react-dom: 18.3.1No changes are required here.
packages/constants/package.json (1)
36-39: Centralizing TS toolchain via catalog looks good.Moving @types/react, tsup, and typescript to "catalog:" will keep this package in sync with the workspace without local drift. No issues from this file alone.
apps/space/package.json (2)
47-48: React and React-DOM alignment confirmed
- Verified
apps/space/package.jsonis on Next 14.2.30.- Confirmed in
pnpm-workspace.yamlthat bothreactandreact-domare pinned to 18.3.1, matching Next 14’s React 18 requirement.No changes needed.
64-69: The script above will extract thespecifiers:mapping from yourpnpm-lock.yamland show the resolved package entries (and their versions) forreact,@types/react, and@types/react-dom. Once you share the output, we can confirm that all majors are indeed in lockstep.apps/web/package.json (1)
53-56: Switch to catalog for react/react-dom looks good; confirm compatibility with Next 14.2.30.Using catalog centralizes these core versions—nice. Just double-check that the catalog pins React/DOM to versions compatible with next@14.2.30 across all apps to avoid subtle hydration issues.
packages/hooks/package.json (2)
24-25: React moved to catalog—LGTM.Centralized React versioning reduces drift between packages consuming hooks.
30-33: tsup and TypeScript via catalog—ensure toolchain compat.tsup 8.4.0 and TypeScript 5.8.3 should be fine together, but flagging to ensure your CI uses a pnpm version that supports catalogs (pnpm >= 9). See workspace comment for a verification script.
packages/types/package.json (1)
36-40: Dev toolchain consolidated via catalog—LGTM.Keeps TS/types/tsup in lockstep across packages.
packages/utils/package.json (1)
31-31: React via catalog—LGTM.Reduces duplicate React versions creeping into the graph.
pnpm-workspace.yaml (1)
7-14: Ensure PNPM ≥9 in CI and unify Node types via the catalog
Add the Node types package to
pnpm-workspace.yamlso all packages share the same baseline:catalog: react: 18.3.1 react-dom: 18.3.1 "@types/react": 18.3.1 "@types/react-dom": 18.3.1 typescript: 5.8.3 tsup: 8.4.0 + "@types/node": 22.5.4Pin your CI to a PNPM version that understands the
catalog:block. Inpull-request-build-lint-web-apps.yml, add a “prepare” step before enabling Corepack:- name: Prepare pnpm@9 run: corepack prepare pnpm@^9 --activate - name: Enable Corepack and pnpm run: corepack enable pnpmDouble-check all workflows for PNPM usage and Corepack setup:
rg -n 'corepack|pnpm' .github/workflows/*.yml(Optional) Verify your catalog definitions match your usage by running:
python - <<'PY' import yaml, json, glob data = yaml.safe_load(open('pnpm-workspace.yaml')) or {} defined = set(data.get('catalog', {})) used = set() for f in glob.glob('**/package.json', recursive=True): pkg = json.load(open(f)) for section in ('dependencies','devDependencies','peerDependencies','optionalDependencies'): used |= {k for k,v in pkg.get(section,{}).items() if isinstance(v,str) and v.startswith('catalog:')} print("Missing catalog entries:", sorted(used - defined)) print("Unused catalog entries:", sorted(defined - used)) PYapps/admin/package.json (1)
37-39: React catalog pin compatibility confirmed
- pnpm-workspace.yaml pins both
reactandreact-domto version 18.3.1 (major 18), as shown by the script’s output.- apps/admin/package.json uses the
catalog:alias forreactandreact-dom.- Next.js 14.2.30 requires React 18, so the catalog’s major version (18) aligns perfectly.
No changes needed here.
packages/ui/package.json (1)
71-79: Centralizing @types/react, @types/react-dom, tsup, and typescript via catalog is consistent.No behavior change at runtime; this reduces skew across packages.
Ensure the catalog includes entries for these four keys; the script under apps/admin/package.json prints the catalog for a quick check.
There was a problem hiding this comment.
Pull Request Overview
This PR adds common packages to the PNPM workspace catalog to centralize dependency management across all packages and applications. This refactoring standardizes versions of core dependencies like React, TypeScript, and build tools.
- Adds a
catalogsection inpnpm-workspace.yamlwith shared dependency versions - Migrates all packages to use catalog references instead of hardcoded versions
- Cleans up ESLint configurations by removing redundant parser specifications
- Updates various code files to address linting issues and improve maintainability
Reviewed Changes
Copilot reviewed 129 out of 130 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| pnpm-workspace.yaml | Adds catalog section with standardized dependency versions |
| Multiple package.json files | Updates dependency references to use catalog syntax |
| Multiple .eslintrc.js files | Removes redundant parser specifications |
| packages/utils/src/subscription.ts | Removes unused parameter from function signature |
| packages/propel/src/utils/classname.tsx | Adds tailwind-merge integration for better class merging |
| apps/web/core/services/issue/issue.service.ts | Adds dynamic imports for better code splitting |
| apps/api | Various API improvements including HTML sanitization and bug fixes |
Files not reviewed (1)
- pnpm-lock.yaml: Language not supported
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
JayashTripathy
force-pushed
the
chore-workspace-catalogs
branch
from
701165f to
ffd8753
Compare
JayashTripathy
changed the title
|
Pull Request Linked with Plane Work Items Comment Automatically Generated by Plane |
…re-workspace-catalogs
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/utils/package.json (1)
31-31: Consider making react a peerDependency in a shared utils package.
- As a library, depending on react directly can cause duplicate React copies in consumers. Prefer peerDependencies + devDependency for local builds.
Apply within this block:
- "react": "catalog:",And add near the bottom (adjust commas as needed):
+ "peerDependencies": { + "react": "catalog:" + },Optionally add for local dev/build:
"devDependencies": { + "react": "catalog:",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (19)
apps/admin/package.json(2 hunks)apps/live/package.json(1 hunks)apps/space/package.json(2 hunks)apps/web/package.json(2 hunks)package.json(1 hunks)packages/constants/package.json(1 hunks)packages/decorators/package.json(1 hunks)packages/editor/package.json(2 hunks)packages/eslint-config/package.json(1 hunks)packages/hooks/package.json(1 hunks)packages/i18n/package.json(1 hunks)packages/logger/package.json(1 hunks)packages/propel/package.json(2 hunks)packages/services/package.json(1 hunks)packages/shared-state/package.json(1 hunks)packages/types/package.json(1 hunks)packages/ui/package.json(2 hunks)packages/utils/package.json(2 hunks)pnpm-workspace.yaml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (17)
- packages/services/package.json
- packages/shared-state/package.json
- packages/ui/package.json
- packages/hooks/package.json
- packages/types/package.json
- packages/i18n/package.json
- package.json
- apps/web/package.json
- packages/constants/package.json
- packages/logger/package.json
- packages/propel/package.json
- packages/editor/package.json
- apps/admin/package.json
- apps/live/package.json
- packages/eslint-config/package.json
- pnpm-workspace.yaml
- packages/decorators/package.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-29T08:45:15.953Z
Learnt from: sriramveeraghanta
PR: makeplane/plane#7672
File: pnpm-workspace.yaml:8-9
Timestamp: 2025-08-29T08:45:15.953Z
Learning: The makeplane/plane repository uses pnpm v10.12.1, which supports onlyBuiltDependencies configuration in pnpm-workspace.yaml files.
Applied to files:
packages/utils/package.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Build and lint web apps
- GitHub Check: Analyze (javascript)
🔇 Additional comments (3)
apps/space/package.json (2)
47-49: Catalog pins satisfy Next@14.2.32 peerDependencies.
Root catalog defines react@18.3.1 and react-dom@18.3.1, which satisfy Next@14.2.32’s ^18.2.0 peerDependency requirements.
64-68: Workspace-level TS (v5.8.3) + root override"typescript": "catalog:"are consistent; verify@types/react&@types/react-domare available in thecatalogregistry.packages/utils/package.json (1)
41-45: Catalog pins verified: pnpm-workspace.yaml includes bothtypescript(5.8.3) andtsup(8.4.0), andpackages/utils/package.jsoncorrectly pins@types/react,tsup, andtypescriptto the catalog.
Description
This PR adds common packages to PNPM workspace catalog. Which will make managing dependencies easier.
Type of Change
Screenshots and Media (if applicable)
Test Scenarios
References
Summary by CodeRabbit