Skip to content
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

Sharable dependency version specifiers #4844

Open
jakeleventhal opened this issue Sep 10, 2023 · 14 comments
Open

Sharable dependency version specifiers #4844

jakeleventhal opened this issue Sep 10, 2023 · 14 comments
Labels
enhancement New feature or request

Comments

@jakeleventhal
Copy link

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

@jakeleventhal jakeleventhal added the enhancement New feature or request label Sep 10, 2023
@espenja
Copy link

espenja commented Sep 10, 2023

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
Copy link

Isn't this resolutions / overrides support ? #1134

@jakeleventhal
Copy link
Author

@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
Copy link

@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
Copy link
Author

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

@Hebilicious
Copy link

@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
Copy link
Author

Solution worksforme

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

@Hebilicious
Copy link

Hebilicious commented Sep 12, 2023

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
Copy link
Author

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
Copy link

unional commented Sep 18, 2023

@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
Copy link
Author

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

@chimericdream
Copy link

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
Copy link

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

@coolcorexix
Copy link

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

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

No branches or pull requests

7 participants