How should you add packages?

[emmatown]

Before looking at this, please review #10.

Adding packages isn't a great experience with these constraints right now.

I've got a kinda mostly working implementation to solve part of this right now but I want to think about this more because I think it's more of a nuanced thing than my implementation looks like right now.

I think there are two things that a user wants at different times when they add a dependency in a monorepo.

1. Add a package as a dep to a package at the same version if it is already a dependency elsewhere in the monorepo, otherwise add the latest version of the package
2. Add the latest version of a package, if it is a dependency elsewhere in the monorepo, update it there

The question is, how should people do this? Bolt did 1 and that seemed to work mostly well so maybe the answer is to only have 1 and then maybe also a way to upgrade packages? The thing that's implemented right now(which I think is broken) works like this yarn m add <theThing>and does 1

Slightly related but also a bit separate thing that's not really a problem because I think the solution is pretty good: Adding peerDependencies

In Yarn and npm(I think), when using the --peer flag adds a package as a peerDependency but you generally also want it as a devDependency. Because of the peer and dev dependency relationship check, we already enforce that. This means that Manypkg's --peer flag on whatever add command might exist should also add the dep as a devDependency.

[Noviny]

Personal thoughts, doing 1 by default seems the most sane - upgrading packages accidentally is a bit scary (I've got a related brown bag topic on this)

Aside aside, are we assuming manypkg should be responsible for package installs? I thought we were handing that off to yarn?

2 seems useful when you want to finally upgrade. My hack workflow for this would be manually update a version in one package and run yarn manypkg --fix

(my hack way of getting the installs I want would probably be to run yarn add THING && yarn manypkg --fix && yarn, which is I guess the argument for why manypkg wants to at least partially handle the installs.)

---

If we're handling installs, I would make --peer install it as a peerDep and a devDep all in one.

[emmatown]

Aside aside, are we assuming manypkg should be responsible for package installs? I thought we were handing that off to yarn?

We're still calling out to yarn to do the actual installing of packages but for 1, doing the package.json modification ourselves seems easier.

My hack workflow for this would be manually update a version in one package and run yarn manypkg --fix

This would currently work, the one problem I have with it though is that it means explaining how to add a package is "run Manypkg this command for this case" and "run Yarn and then Manypkg for this other case" for this other case which doesn't feel super good.

[Noviny]

With 1, can we do:

• get the version range found in repo
• call yarn add package@found-range

Offloading even more of this to yarn? (Trying to keep the wrapper very thin)

Oh I wasn’t saying my hack was good. It’s tbh probably the reason to do this over bolt-check

[emmatown]

With 1, can we do:

• get the version range found in repo
• call yarn add package@found-range

Offloading even more of this to yarn? (Trying to keep the wrapper very thin)

My fear with doing this is that I've experienced strange problems with running yarn add inside workspaces with resolutions not being respected and having to run yarn at the root to fix the things + if someone runs add with a range specified that's different from the other versions in the repo that's not the version in other places in the repo, we would have to do lots of installs but it's only one if we do the package.json modifications ourselves and then call out to yarn to install All The Right Things.

[Noviny]

strange problems with running yarn add inside workspaces with resolutions not being respected

Wouldn't mind expanding on this - that seems a fairly hard blocker, you're right.

if someone runs add with a range specified

I guess we should align assumptions - if someone runs add for existing-external-dep@^1.5.0 and it's different to the other versions in the repo, I assume it errors eed is already present at ^1.3.0 - upgrade existing dependencies if you want to install ^1.5.0 in the repository.

That said, this probably implies an upgrade command which really should just do package.json updating and a root yarn call, which we can share more code with if this does package.json modifying.