Monorepo projects not working on deploy

[Nick Seagull]

Reported by @DKarandikar (Danno212 on Discord)

Current Behavior

The sandbox created by copying over src/, package.json, package-lock.json, and tsconfig.json always uses npm to install. When trying to deploy the project, the following error occurs:

npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "workspace:": workspace:^1.0.0

Expected behavior

The Turborepo Monorepo should be able to deploy without encountering any NPM errors.

Possible Solution

A solution may involve modifying the package configuration files to avoid the use of the workspace: URL type, this would probably require package flattening. Another solution would be to pack the dependencies into files and then replace the dependency versions by the path to the tar.gz files

[Daniel Karandikar]

To expand on this a bit, Booster apps in monorepos (e.g. TurboRepo or Rush) fail to deploy if this app has any local imports ("Internal Packages" in TurboRepo.)

For example:

├── apps
│   └── booster-project
│       ├── src
│       │   └── index.ts
│       └── package.json
├── packages
│   └── helper
│       ├── src
│       │   └── index.ts
│       ├── tsconfig.json
│       └── package.json
├── package.json

Where the booster-project package.json includes a dependency: "helper": "workspace:^1.0.0".

This seems to be due to the Sandboxing stage, which copies over package.json and the src/ directory from the Booster package, then does an npm install --production. Inside the sandbox npm can't make sense of these internal packages and either reports that it can't find the package in the configured repositories, or throws the above error in the case of workspace:... versions.

Our workaround for this is to compile internal packages into js as a first step. Then, as part of the deployment, copy the output folder and package.json for internal packages into the root of the Booster app, and define these as static assets in config. In addition, this requires rewriting the package.json of the Booster app to use file:... versions, which it does understand as of Version 2.0.0 (see here)

[Nick Seagull]

As I've been researching the monorepo tools usually have a command in order to remove the workspace versions by packaging a specific project in the monorepo. For example, Rush has a rush deploy command that does it.

A plan that comes to my mind is to move the createSandboxProject function into the PackageManager service and calling it deploy or something. Then implement it with those commands for each tool