Open jakeleventhal opened 1 year ago
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 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 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 specify1.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 and how would that work for child package.json? what version specifier would you use for axios
@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 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.
Update, this is now implemented in pnpm@9.5.0
(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
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
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