Monorepo workspaces

proposal.md

Yarn workspaces (as I understand them) use the root of the Lerna-style repository to install node_modules. Lerna-style repos tend to contain libraries rather than apps, though.

In a monorepo with multiple apps, we want each app to have its own node_modules directory. This is so that each app's node_modules directory contains only that app's dependencies, which can lead to better deduping for that app. Also if an app has postinstall scripts that modify node_modules, those scripts should modify only that app's node_modules.

How can we combine parts of these two worlds? If an app depends on other packages inside the same monorepo, we (usually) want to use those local packages. We also want each app to have its own node_modules.

One idea is for each app's package.json to declare a "workspace" key with deps/devDeps to install.

{
  "workspace": {
    "dependencies": {
      "typeaheadpro": "<rootDir>/libraries/typeaheadpro"
    },
    "devDependencies": {
      "jest-preset": "<rootDir>/testing/jest-preset"
    }
  }
}

When installing this app's dependencies with a special workspace command (yarn install --workspace?), Yarn would install the app's dependencies (listed under the regular deps/devDeps keys) except for the ones listed under workspace.dependencies and workspace.devDependencies. For the workspace dependencies, Yarn would go into those dependencies' directories, run yarn pack (to simulate publishing) and then in the app's directory run yarn add <the packed tar.gz> --pure-lockfile (to install the library in the app). This way we're now using local copies of the libraries as if they had been published to npm.

This proposal could also incorporate a --link flag. If you run yarn install --workspace --link in an app's directory, instead of running yarn pack for each of the workspace dependencies, Yarn would run yarn knit (or whatever that command ends up being called), which also simulates publishing (this is key! gonna want that parity between development and production) but uses symlinks.

@ide you have some valid use case here.

First gut feeling is to reject term "workspaces" because it is associated in my mind with the structure babel and jest repos have.
I would not want to overload it.

Do you want something like you knit proposal but in an automated way?

Please cc us when answering, I did not find a way to subscribe