This is lovely! I'm 100 % supportive of this plan. Can we call it experimentalWorkspace in the first iteration?

How about we disable this feature behind and experimental-workspaces flag?

So for every workspace feature I'd have to type out --experimental-workspaces or do I put that in my yarnrc?

In .yarnrc:

yarn-offline-mirror "tarballs"
disable-self-update-check true
experimental-workspaces true

Sounds good.

This isn't really how RFCs are supposed to work... there's a lot of missing details here that should be added

I am open to suggestions here, @thejameskyle.
Can you point to which details are missing?

I added a lot more detail to my original RFC here: https://gist.github.com/thejameskyle/1e0f781de728ec1f2597a0bdbe071675

#62

Looking at workspaces (or: multi-project builds, or: multi-modules) from a Gradle (or: maven) perspective, there's that dependencyManagement feature where version numbers are managed by the parent project. Child projects specity what dependency they need and take it with the version number as managed by the parent.

In a multi-project yarn set-up, we do this by writing a "x.y.z" (or some other placeholder) to the child package.json. The parent package.json specifies version numbers. It looks like this:

package.json

{
  "name": "parent",
  "private": true,
  "dependencies": {
    "a": "1.0.0",
    "b": "^2.4.7"
  }
}

packages/common/package.json:

{
  "name": "common",
  "dependencies": {
    "a": "x.y.z"
  }
}

packages/utils/package.json:

{
  "name": "core",
  "dependencies": {
    "a": "x.y.z",
    "b": "x.y.z"
  }
}

I think it could be super-helpful to add a "parent" or "inherit" virtual version number (instead of the "x.y.z" in the example, naming and label can be discussed), telling yarn to re-use the version from the parent package.

@dherges that would risk a nonstandard version string being published out to the ecosystem. The inner package package.jsons need to be coded as if the parent workspace doesn't exist, since when published, it won't.

@ljharb yes, you're right. it would require to build an effective package.json and prevent the original package.json from being published.

@dherges which is a very error-prone approach, considering anyone might run npm publish by accident, instead of yarn publish.

@ljharb partially, yes. we work around this by managing publishConfig and private fields in our build scripts and then only final package.json has the right publishConfig applied. doing this would require yarn workspaces to assume a lot of about the build system, e.g. manage a source folder, manage a dist folder, and so on.