Introduce catalogs support

What is the problem this feature would solve?

In a monorepo, it would be cool to specify a single set of package pins at the repo root and those could then just be used throughout the repository instead of needing to be specified in numerous places.

Here is the PNPM RFC for accomplishing this: pnpm/rfcs#1

What is the feature you are proposing to solve the problem?

Sharable package pins accross a monorepo

What alternatives have you considered?

No response

Agree with this. It feels very unnecessary being forced to install "common" packages for a monorepo into every single workspace package. Examples include specific typescript version, eslint, prettier. Packages installed in the root dev/dependencies should be automatically resolvable by all workspace packages. If a package must use a specific version it can be defined in it's respective package.json. This should further lead to individual packages not straying away from the versions used by the entire repo.

Isn't this resolutions / overrides support ? #1134

@Hebilicious

@Hebilicious no, this is different

This PR is really for monorepos. For instance, if I use axios, i want to be able to specify that axios should use version 1.2.3. If my monorepo has 30 package.json files that use axios, i want to just be able to specify 1.2.3 once in some root configuration and then all my packages can just use "axios": "workspace:*"

@Hebilicious

@Hebilicious no, this is different

This PR is really for monorepos. For instance, if I use axios, i want to be able to specify that axios should use version 1.2.3. If my monorepo has 30 package.json files that use axios, i want to just be able to specify 1.2.3 once in some root configuration and then all my packages can just use "axios": "workspace:*"

Bun could add workspace:* support to resolutions/overrides so these would get resolved without introducing a new configuration syntax. You'd specify "axios": "1.2.3:*" in the resolutions/overrides of a monorepo root package.json.

@Hebilicious

@Hebilicious and how would that work for child package.json? what version specifier would you use for axios

@Hebilicious

@Hebilicious and how would that work for child package.json? what version specifier would you use for axios

You can use anything, incuding workspace:*. It will get replaced by whatever version overrides/resolutions has.

Solution worksforme

But I think consulting the PNPM rfc makes should be done. a lot of thought/effort went into that

Solution worksforme

But I think consulting the PNPM rfc makes should be done. a lot of thought/effort went into that

This RFC is quite long, I would suggest you update the description here with more accurate information. There's a subtle difference with overrides/resolutions that is documented here.
Note that this isn't implemented by any package manager so far, so it would be a non standard behaviour that bun could align with pnpms if they decide to go with catalog

I don't really have much skin in the game. Either solution works, but I think for the JS ecosystem it would be preferable if PNPM and bun were in sync here. That way, switching to bun can be even more of a "drop in replacement"

@Hebilicious

@Hebilicious and how would that work for child package.json? what version specifier would you use for axios

You can use anything, incuding workspace:*. It will get replaced by whatever version overrides/resolutions has.

I would suggest to recommend only workspace:* (or ^. Personally I think workspace:^1.2.3 is noise and can complicate things quite a lot).

Replacing "anything" is technically correct as it is really just an override,
but using workspace:* have specific meaning.

@Jarred-Sumner

Update, this is now implemented in pnpm@9.5.0 (see pnpm/pnpm#7072)

@Jarred-Sumner should bun just "work" here with the same syntax? Hard to tell with the binary bun lockfile

I'm curious if there is any update on whether or when this might be added. We have had a number of minor bugs recently where we had slight mismatches in dependency versions (e.g. i18next ^23.10.1 vs 23.12.2), resulting in two copies of the affected libraries ending up in our bundled app.

For now, I am planning to pin everything to a particular version across our whole monorepo, but that isn't a sustainable approach.

Since it's not mentioned, here are the pnpm docs for pnpm catalogs

I tried set workspace:* and it just does not work because this is only used to mention the sub-repo of monorepo not the used packages
reference: https://bun.sh/docs/install/workspaces

Implementation proposal from #18939

package.json or bunfig.toml based implementation of pnpm catalogs

root json

{
  "workspaces": [ "packages/**", "apps/**" ],
  "catalogs": [ { "drizzle-orm": "0.41.0" } ],
}

or

# bunfig.toml
[test]
preload = "./happydom.ts"

[catalogs]
"drizzle-orm" = "0.41.0"

with end use looking like

{
  "dependencies": {
    "drizzle-orm": "catalog:",
    "next": "^15",
  }
}

Personally I think all the gestion of the packages for this should stay in the root package.json. I think an implementation like this should be the best considering that workspaces are already declared there.

Example of root package.json :

{
  "name": "package-name",
  "version": "0.0.1",
  "scripts": {
      ...
  },
  "devDependencies": {
      ...
  },
  "workspaces": ["apps/*", "packages/*"],
  "catalogDependencies": {
      "typescript": "5.7.3",
      "@types/bun": "^1.2.9"
  }
}

Maybe the name can be like : catDependencies, sharedDependencies, globalDependencies or something like that.
For me this feature is stopping me in the usage of Bun in monorepo.

The issue is interesting and I totally agree that it should be defined in the package.json

But what do we do with the JSON schema (but it is not strict as I remember)?
What if npm wants to add something with the same key...

Yes I know that a problem. But if Bun implement the pnpm-worspace.yml it will be weird. The best would be that a common method would be follow by pnpm and bun but also other package manager.

Yes I know that a problem. But if Bun implement the pnpm-worspace.yml it will be weird. The best would be that a common method would be follow by pnpm and bun but also other package manager.

it should be a universal implementation that respects pnpm-worksapce and package.json so that bun is plug and play

tbf migrating a pnpm workspace catalog to another spec takes 30 seconds and is only done in one place as long as the "dep": "catalog:" is the schema for use

Yes I know that a problem. But if Bun implement the pnpm-worspace.yml it will be weird. The best would be that a common method would be follow by pnpm and bun but also other package manager.

bun should not implement it yeah
maybe only migration can help

lets wait what Bun team will say

We are planning to implement support for catalogs.

We probably will later add a pnpm-workspace.yml migration path, but unlikely with the initial version of catalogs.

bun install will ship support for catalogs in the next release (Bun v.1.2.14). Catalogs work the same way as in pnpm, except they are listed under "workspaces.catalog(s)" in your root package.json instead of in pnpm-workspaces.yaml. Example:

./package.json:

{
  "name": "bun-catalogs",
  "version": "1.0.0",
  "workspaces": {
    "packages": ["packages/*"],
    "catalog": {
      "jquery": "3.7.1"
    },
    "catalogs": {
      "beta": {
        "zod": "4.0.0-beta.20250505T195954"
      }
    }
  }
}

./packages/pkg1/package.json:

{
    "name": "pkg1",
    "dependencies": {
        "jquery": "catalog:",
        "zod": "catalog:beta"
    }
}

bun publish will also replace catalog: with the catalog version, similar to workspace:.

Awesome! Great to see bun getting more modern package management abilities. Are there plans to add more control over hoisting (a more "correct" node_modules like pnpm does)? Lots of discussion over in #533

any chances of adding support to move packages and catalogs to a separate file similar to pnpm-workspace.yml ?

@elfala7elfasee7

@elfala7elfasee7 this happens automatically when you run bun install

Navigation Menu

Repository navigation

Introduce catalogs support #4844

What is the problem this feature would solve?

What is the feature you are proposing to solve the problem?

What alternatives have you considered?

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Introduce catalogs support #4844

Description

What is the problem this feature would solve?

What is the feature you are proposing to solve the problem?

What alternatives have you considered?

Activity

espenja commented on Sep 10, 2023

Hebilicious commented on Sep 11, 2023

jakeleventhal commented on Sep 11, 2023

Hebilicious commented on Sep 11, 2023

jakeleventhal commented on Sep 11, 2023

Hebilicious commented on Sep 11, 2023

jakeleventhal commented on Sep 11, 2023

Hebilicious commented on Sep 12, 2023

jakeleventhal commented on Sep 12, 2023

unional commented on Sep 18, 2023

jakeleventhal commented on Jul 9, 2024

chimericdream commented on Aug 14, 2024

austinm911 commented on Aug 24, 2024

coolcorexix commented on Sep 25, 2024

10 remaining items

versecafe commented on Apr 12, 2025

Marius-brt commented on Apr 14, 2025

kravetsone commented on Apr 14, 2025

Marius-brt commented on Apr 14, 2025

jakeleventhal commented on Apr 15, 2025

versecafe commented on Apr 15, 2025

kravetsone commented on Apr 15, 2025

Jarred-Sumner commented on May 13, 2025

dylan-conway commented on May 21, 2025

evelant commented on May 21, 2025

elfala7elfasee7 commented on Oct 27, 2025

jakeleventhal commented on Oct 27, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions