Skip to content

chore: use catalog for dependencies across multiple packages and the website #7824

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

bjohansebas
Copy link
Member

Description

Using a catalog allows you to define a dependency in a single place and share it with the rest of the packages that require it. This can be useful to ensure that the same dependencies are always shared consistently

Validation

Related Issues

https://openjs-foundation.slack.com/archives/CVAMEJ4UV/p1748813652063899

Check List

  • I have read the Contributing Guidelines and made commit messages that follow the guideline.
  • I have run pnpm format to ensure the code follows the style guide.
  • I have run pnpm test to check if all tests are passing.
  • I have run pnpm build to check if the website builds without errors.
  • I've covered new added functionality with unit tests if necessary.

Copy link

vercel bot commented Jun 1, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
nodejs-org ✅ Ready (Inspect) Visit Preview Jun 1, 2025 10:04pm

Copy link

codecov bot commented Jun 1, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.46%. Comparing base (c11af00) to head (6fb1425).

✅ All tests successful. No failed tests found.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #7824      +/-   ##
==========================================
- Coverage   75.48%   75.46%   -0.03%     
==========================================
  Files         101      101              
  Lines        8309     8309              
  Branches      218      218              
==========================================
- Hits         6272     6270       -2     
- Misses       2035     2037       +2     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@bjohansebas bjohansebas marked this pull request as ready for review June 1, 2025 22:07
@Copilot Copilot AI review requested due to automatic review settings June 1, 2025 22:07
@bjohansebas bjohansebas requested a review from a team as a code owner June 1, 2025 22:07
Copilot

This comment was marked as resolved.

Comment on lines +20 to +26
catalog:
'@types/node': 22.15.3
'@types/react': ^19.1.0
classnames: ~2.5.1
react: ^19.1.0
tailwindcss: ~4.0.17
typescript: ~5.8.2
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These were the dependencies I saw repeated more than once across all the packages and the website. Feel free to suggest any that might be missing.

Copy link
Member

@avivkeller avivkeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When the packages are published, will these be replaced with normal versions?

Edit: Yes, see https://pnpm.io/catalogs#publishing

@avivkeller
Copy link
Member

If we do this, I'm slightly inclined to do it to all of our packages.

@bjohansebas
Copy link
Member Author

If we do this, I'm slightly inclined to do it to all of our packages.

It would be good to include only the dependencies that are repeated across packages, we don’t want
to fill this list with all the dependencies.

Copy link
Member

@AugustinMauroy AugustinMauroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://pnpm.io/catalogs#caveats

will these dep be updated by dependabot?

@bjohansebas
Copy link
Member Author

yes https://github.blog/changelog/2025-02-04-dependabot-now-supports-pnpm-workspace-catalogs-ga

# multiple packages in the monorepo.
# This allows us to manage versions and updates in one place.
# https://pnpm.io/en/catalogs

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

@@ -106,7 +106,7 @@
"stylelint-order": "7.0.0",
"stylelint-selector-bem-pattern": "4.0.1",
"tsx": "^4.19.3",
"typescript": "~5.8.2",
"typescript": "catalog:",
"typescript-eslint": "~8.31.1",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe add typescript-eslint?

"@types/node": "22.15.3",
"@types/react": "^19.1.0",
"@types/node": "catalog:",
"@types/react": "catalog:",
"cross-env": "^7.0.3",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add cross-env

"cross-env": "^7.0.3",
"css-loader": "~7.1.2",
"eslint-plugin-react": "~7.37.4",
"eslint-plugin-storybook": "~0.12.0",
"global-jsdom": "^26.0.0",
"postcss-loader": "~8.1.1",
"react": "^19.1.0",
"react": "catalog:",
"storybook": "^8.6.11",
"style-loader": "~4.0.0",
"stylelint": "^16.19.1",
"stylelint-config-standard": "^38.0.0",
"stylelint-order": "7.0.0",
"stylelint-selector-bem-pattern": "4.0.1",
"tsx": "^4.19.3",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should add our testing deps, like tsx JSdom, etc?

@avivkeller
Copy link
Member

It would be good to include only the dependencies that are repeated across packages

That also sounds good, but I don't think we should selectively include, I feel we should either:
None
All repeated
All

But that's just me

@MattIPv4
Copy link
Member

MattIPv4 commented Jun 6, 2025

Very much as an aside, but I am surprised none of the changes in this PR require approval from web-infra as a code owner.

@ovflowd
Copy link
Member

ovflowd commented Jun 6, 2025

Is this catalog: syntax compatible with npm? Is this a more-or-less standard field in package.json?

@ovflowd
Copy link
Member

ovflowd commented Jun 6, 2025

Very much as an aside, but I am surprised none of the changes in this PR require approval from web-infra as a code owner.

Agreed. These sort of changes should require web-infra as per the governance, they're not specifically related as a website development feature but more an infrastructural aspect.

@MattIPv4
Copy link
Member

MattIPv4 commented Jun 6, 2025

Is this catalog: syntax compatible with npm? Is this a more-or-less standard field in package.json?

It relies on pnpm-workspace.yaml to work, so no, npm will not support it AIUI.

@avivkeller
Copy link
Member

avivkeller commented Jun 6, 2025

Is this catalog: syntax compatible with npm? Is this a more-or-less standard field in package.json?

#7824 (review)

It relies on pnpm-workspace.yaml to work, so no, npm will not support it AIUI.

When we run pnpm publish, it gets replaced with the standard versions, so npm will support it, unless you import directly from the git repo

Copy link
Member

@ovflowd ovflowd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate the effort, @bjohansebas but I'm -1 on features that are locked on a specific package manager.

@MattIPv4
Copy link
Member

MattIPv4 commented Jun 6, 2025

Appreciate the effort, @bjohansebas but I'm -1 on features that are locked on a specific package manager.

With all the respect in the world, this feels like a ridiculous reason to object when we 1. voted to use pnpm, and 2. are specifically enforcing that pnpm is used when contributing:

nodejs.org/package.json

Lines 54 to 59 in ed840c2

"devEngines": {
"packageManager": {
"name": "pnpm",
"version": "10.11.1"
}
}

Copy link
Member

@avivkeller avivkeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @ovflowd — this change introduces an additional layer of complexity that contributors will need to learn, which could make contributing harder.

Also, it’s worth pointing out that if the consumer is importing via git subdirectories, this approach requires them to use pnpm, ruling out alternatives like yarn that also support git subdirectory imports.

@MattIPv4
Copy link
Member

MattIPv4 commented Jun 7, 2025

Also, it’s worth pointing out that if the consumer is importing via git subdirectories, this approach requires them to use pnpm, ruling out alternatives like yarn that also support git subdirectory imports.

Out of curiosity, we already use workspace: directives in here, do those work w/ git subdirectory imports w/ yarn/pnpm? Are they both smart enough to resolve those to the git repository as a whole?

@MattIPv4
Copy link
Member

MattIPv4 commented Jun 7, 2025

I expressed this in Slack, but honestly, I'm quite disappointed with the objections here, both because we actively voted to use pnpm yet are now against using the niceties it gives us, but also because I don't see how this is particularly anymore complex than the workspace: syntax we already use which also require additional mental overhead to understand, resolving a version to elsewhere in the repository, very similar to what catalog: is doing.

@avivkeller
Copy link
Member

Out of curiosity, we already use workspace: directives in here, do those work w/ git subdirectory imports w/ yarn/pnpm? Are they both smart enough to resolve those to the git repository as a whole?

We intentionally avoid using the workspace: syntax within packages/ to allow for package manager independent imports. We aren't expecting anyone to import apps/site, so we make use of it there.

@ovflowd
Copy link
Member

ovflowd commented Jun 7, 2025

I expressed this in Slack, but honestly, I'm quite disappointed with the objections here, both because we actively voted to use pnpm

I recall our votes were explicitly to use pnpm in favor for our CI/CD and improve installation speed. I don't think we voted on using pnpm specific features that are only available for pnpm. I did not recall the PR that added pnpm-workspaces.yml and I'm pretty sure pnpm is compatible with npm workspaces. (https://docs.npmjs.com/cli/v7/using-npm/workspaces)

I also feel we should use syntax as much as possible that is cross-compatible with other package managers. Although yes, users will be asked to use pnpm when installing due to the requirements we added on package.json, I do feel that:

a) i should be able to install via npm or yarn or deno or bun or whatever I want
b) we probably should remove the explicit pnpm requirement, I believe that's the packageManager field (https://github.com/nodejs/nodejs.org/blob/main/package.json#L50) as if I recall devEngines is what dependabot uses? Please correct me if I'm wrong.

But I want to make it explicit that our vote fas in favor of using pnpm by default due to the reasons I listed above; Making it exclusory or using pnpm-only terminology isn't just a learning curve, it is blocking users from choosing their own package manager.

There's a Collaboration Space within OpenJS with the specific goal of making Package Managers Interoperable; I feel dubious that whilst OpenJS is working towards that (ie @Ethan-Arrowood) we are doing the opposite by locking down our repo to only work with pnpm.

@avivkeller
Copy link
Member

I did not recall the PR that added pnpm-workspaces.yml and I'm pretty sure pnpm is compatible with npm workspaces. (https://docs.npmjs.com/cli/v7/using-npm/workspaces)

We added that in the initial migration, IIRC. I didn't know pnpm supported npm workspaces.


For devEngines, we explicitly voted to set both of them, so, at the very least, I would feel more comfortable calling a second vote if we wanted to change it.

@ovflowd
Copy link
Member

ovflowd commented Jun 7, 2025

For devEngines, we explicitly voted to set both of them, so, at the very least, I would feel more comfortable calling a second vote if we wanted to change it.

I recall that yes; But didn't realize npm would block you from using it due to packageManager.

We added that in the initial migration, IIRC. I didn't know pnpm supported npm workspaces.

As far as I know pnpm, yarn and npm support the simplified workspace: setting on package.json... Maybe you could experiment w/ that?

Copy link
Member

@ovflowd ovflowd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI I don't want to block the PR unnecessarily, and apparently pnpm does NOT support NPM's workspace... and we're already using yarn/pnpm specific syntax with workspace:* so let's gon ahead with this PR.

@avivkeller avivkeller dismissed their stale review June 8, 2025 16:34

I still am -1 on this, but I am the minority, so I don't want to block this PR when everyone else is okay with it

Copy link
Member

@AugustinMauroy AugustinMauroy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not but catalog is a new npm feature so idk if it's good idea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants