support importing directories from github pnpm monorepo

🌈 Feature

Support importing sub-directories from github (already supported) that are part of a monorepo (not supported).

Examples of things that get in the way of this working:

1. Understanding "catalog:" versions (https://pnpm.io/catalogs)
2. Understanding "workspace:" versions (https://pnpm.io/workspaces)
3. Other things?

How it would work

The two ways I can think of supporting this feature are:

Option A (easier):

support a sandbox.config.json setting to replace monorepo specifiers. You could have a simple setting for now in sandbox.config.json that is something like "replaceAllMonorepoSpecifiersWith": "latest", which would automatically replace "catalog:" and "workspace:" to "latest" in package.json in the sandbox. There's a lot of assumptions here (such as all monorepo package dependencies being published and public). But why would you put a thing that depends on private packages in a codesandbox anyway?

Option B (harder):

Support pushing the directory as a package into codesandbox, with the versions resolved to hard-coded version specifiers that any package manager can understand (e.g. replace "workspace:" with "1.0.0").

Why I want this

I've always tried to have an examples directory in my monorepo of my open source npm packages that can be one-click opened in codesandbox. For example, this guy: https://github.com/altano/npm-packages/tree/main/examples/satori-fit-text-node-cli

The hard thing about doing this has always been keeping the version hard-coded. There aren't great releases tools that make such examples easy to maintain in a monorepo AND let you hard-code the version. For example, changesets, a very popular tool for this, doesn't work with pnpm. It will update the internal package's version in the example package.json, but it won't update pnpm-lock.yaml (https://github.com/changesets/changesets/issues/1148). And even if it did, you're still not pointing your example at the latest version of your internal package in your monorepo whenever you hard-code the version number.

Start by tracing the existing GitHub sub-directory import flow and inspect how sandbox.config.json, package.json, and pnpm-lock.yaml are handled. Compare the proposed specifier-replacement and package-pushing approaches, then define tests showing that pnpm catalog: and workspace: dependencies import successfully; done means supported monorepo sub-directories open in CodeSandbox.