[Feature] don't require worktrees to be private

[trusktr]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

Having workspaces nested inside workspaces could be a nice way to organize development of packages, where one package being a worktree may depend on other packages that are closely associated to it and those closely-associated packages are developed as yarn workspaces in the main package. The worktree itself could be an "umbrella package" where it simply re-exports all of the sub-packages, for example.

Furthermore, the "umbrella package" which is being developed as a yarn worktree, may itself be a workspace in a larger project that depends on the "umbrella package".

Honestly, I don't think people will accidentally publish the worktree if they don't want to. It is very easy to learn not to publish a package on accident (and I my self have never done that and can not imagine how I would end up accidentally publishing a package, which seems to require a lot of carelessness, and publishing packages carelessly isn't going to get anyone far).

Describe the solution you'd like

I'd like to make the root of a worktree not private, so that I can publish it on NPM. This worktree root may be an NPM package that depends on a few other closely-related packages that are workspaces inside the worktree for easier development, but at runtime the workspaces are imported as regular dependencies when consumed by other projects.

I'm currently in the research phase of tools, and have been looking at Rush, Yarn, pnpm, Lerna, and Bolt.

So far Yarn seems to be the only tool that explicitly documents its ability to have nested work trees, but unfortunately with the requirement of private: true. I haven't tried this with pnpm, because pnpm doesn't support prepare or prepack scripts yet, so pnpm isn't even an option I can try yet.

Describe the drawbacks of your solution

None that I know of. Being able to publish a worktree is in my eyes not a drawback.

I would make sure that my publish steps only publish dist, and not the workspaces in the worktree.

Describe alternatives you've considered

I tried to do this with Rush.js, but its commands fail when using git submodules for projects ("projects" in Rush being equivalent to "workspaces" in Yarn).

[arcanis]

Back in the 1.x the worktrees used to implicitly depend on its workspaces, so it could be quite dangerous to discard the private field as it could lead to an incorrect package being published.

The 2.x worktrees require explicit dependency listing (including workspaces), so this case doesn't happen as much. Maybe this requirement could be relaxed.

Honestly, I don't think people will accidentally publish the worktree if they don't want to. It is very easy to learn not to publish a package on accident (and I my self have never done that and can not imagine how I would end up accidentally publishing a package, which seems to require a lot of carelessness, and publishing packages carelessly isn't going to get anyone far).

I myself avoided a few accidental pushes this way, and I have some experience of package managers 😉

[merceyz]

Closing as this has been implemented