adhoc workspaces for specific cross-repo tasks

[serapath]

I work with other open source devs and frequently need to work on tasks where i need to clone a few repos which depend on each other to edit them so i can fix a cross repo bug or add a cross repo feature and i think thats something many people frequently need to do.

In fact it can be so annoying, people invented mono repos and are scared to depend on modules not invented in the monorepo just to avoid the need to work on multiple repos.

Maybe this can be solved if it was easier to create short lived task based adhoc workspaces

---

The rough idea i got goes as follows:

1. configure where to store git repos of packages

• .npmrc#store-dir="~/.pnpm-store" might contain all installed packages
• .npmrc#repo-dir="~/sourcecode" could be a place to contain github repos

2. to create a task (=adhoc workspace)

~/dev/playground/$> pnpm task <taskname> --repos name1 name2, ..., nameN

which will git clone the corresponding git repos of package.json in ~/.pnpm-store modules with those names into ~/sourcecode or warn or throw or optionally prompt for the repos if the "name" does not yet exist in ~/sourcecode already nor is it defined in ~/.pnpm-store/"name"/package.json and then finally link them into ~/dev/playground/<taskname> where pnpm task ... was executed.

Which would make it look like:

~/dev/playground/<taskname>/repo/name1/name1 -> ~/sourcecode/name1
~/dev/playground/<taskname>/repo/name1/node_modules/...
~/dev/playground/<taskname>/repo/name1/node_modules/name2 -> ../..name2
~/dev/playground/<taskname>/repo/name1/node_modules/nameN -> ../..nameN
~/dev/playground/<taskname>/repo/name2/name2 -> ~/sourcecode/name2
~/dev/playground/<taskname>/repo/name2/node_modules/...
~/dev/playground/<taskname>/repo/name1/node_modules/name1 -> ../..name1
~/dev/playground/<taskname>/repo/name1/node_modules/nameN -> ../..nameN
...
~/dev/playground/<taskname>/repo/nameN/nameN -> ~/sourcecode/nameN
~/dev/playground/<taskname>/repo/nameN/node_modules/...
~/dev/playground/<taskname>/repo/name1/node_modules/name1 -> ../..name1
~/dev/playground/<taskname>/repo/name1/node_modules/name2 -> ../..name2
~/dev/playground/<taskname>/task.json

Where ~/dev/playground/<taskname>/repo/nameX/ will contain
* ./nameX which links the actual git repo in ~/sourcecode/nameX
* ./node_modules/ to have all the dependencies of nameX in addition to other task repos

This would enable other task folders created with pnpm task to work on the same repos but link different kinds of repositories together and change dependencies without interference.

It also contains task.json or task.yaml which signals the "task root directory":

{
  "name": "<taskname>",
  "repo": {
    "name1": git_url_from_package,
    "name2": git_url_from_package,
    ...
    "nameN": git_url_from_package,
  }
}

Now using the capabilities to recursively work on repos and manage them together and execute scripts, maybe define them in task.json would already make things a lot easier. Other features can follow later. But this is the basic idea.

It would enable a special task or issues repository with lots of predefined <taskname>.json or (yaml) files and when cloning that repo or just fetching files from it, i could set myself up adhoc workspace repos to work on specific cross repo features/bugs/concerns.

e.g. pnpm task --fetch github:pnpm/pnpm -- ./tasks/task123.yaml would locally create a folder task123/ as above but use the information already written in task123.yaml`

---

I think some sort of task/issue based adhoc workspace management would be awesome and would make working with cross-repo concerns much easier.
Is that something that would be hard to achieve in the above or somewhat similar style?

[zkochan]

This seems like a huge chunk of work and it would be experimental for a long time. I would suggest to implement it in userland and if there are some specific small feature requests to pnpm, we can discuss on per case basis.