Sharable dependency version specifiers

[jakeleventhal]

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: https://github.com/pnpm/rfcs/pull/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

[espenja]

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.

[Hebilicious]

Isn't this resolutions / overrides support ? #1134

[jakeleventhal]

@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.

[jakeleventhal]

@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.

[jakeleventhal]

Solution worksforme

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

[Hebilicious]

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

[jakeleventhal]

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"

[unional]

@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.

[jakeleventhal]

Update, this is now implemented in [email protected] (see https://github.com/pnpm/pnpm/issues/7072)

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

[chimericdream]

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.

[austinm911]

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

[coolcorexix]

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

[ohroy]

any news?

[mi4uu]

bump! we need this

[karyanayandi]

bump! this feature very helpful

[bbarks15]

bump! only thing stopping me moving away from pnpm

[lucashfreitas]

bump! only thing holding us from moving away from pnpm

[mrtnbroder]

This feature is also stopping me rn from moving to bun (from pnpm). I'd gladly help if there is something I can do!

[erickreutz]

We need this also

[ibufu]

+1

[versecafe]

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",
  }
}

[Marius-brt]

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.

[kravetsone]

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...

[Marius-brt]

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.

[jakeleventhal]

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

[versecafe]

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

[kravetsone]

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

[Jarred-Sumner]

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.