We planned to use workspaces keyword in package.json to identify all sub projects.
I would also try to stay away from term project because this term is overused in IT.
But then what term should we use for the root folder?

As if not overused already: container

I think we should limit the number of terms if possible.
I propose workspaces root and workspaces

@thejameskyle suggested "project" for the workspaces root, and "workspace" for the ... workspaces.

I also had another idea: make the root "workbase". Keep in mind that I'm not a native english speaker so maybe it doesn't make sense, but it feels like a nice way to clearly show that a workspace is contained inside a workbase (because of the "base" suffix). Without this, I fear people will be confused. If "base" doesn't work, maybe something else? Worktree, workroot, workset, ...

There are some specific scenarios that we need to address in this RFC.

For example, from my RFC #60

The structure of the source code is following

| jest/
| ---- package.json
| ---- packages/
| -------- babel-jest/
| ------------ packjage.json
| -------- babel-preset-jest/
| ------------ packjage.json
...

We want to address how we run commands (install/add/upgrade/remove) when CWD is workspace root.
Then what happens if CWD is jest/packages/babel-preset-jest?

How do I update a dependency in a workspace and in a root?

You can use yarn add to add a dependency in the current workspace, or yarn workspace my-workspace add to add a dependency inside a specific workspace from anywhere in the project tree.

One of the things I'd get a bit worries about here is overloading the same command space. There's three different things that fit into this space broken down into two groups:

• yarn workspace <name> <command/run-script> which matches yarn <command/run-script>
• yarn workspace <name> <system-command> (i.e. yarn workspace <name> pwd)

That's why I would like to see a new global command exec (which is similar to lerna exec)

Hm, I see what you mean. The pwd command could be delegated to shell via exec. However, I think it would break the Windows portability. Since the command would run in cmd.exe, the pwd utility wouldn't be available, and users would have to use cd instead. In the end, the command would look like:

$> yarn workspace babel-core exec pwd || yarn workspace babel-core exec cd

Which looks awfully verbose (and not great perf-wise). Adding a builtin pwd command would solve this at virtually no cost, since we would need to compute the path anyway.

Regarding the exec command, I'm not sure how people will end up using it (they should probably register their commands as scripts if they intend to use them regularly, or to use advanced shell structures), but I have no objection implementing it, the maintenance cost shouldn't be very high anyway.

Just one concern: since Yarn already has a run command, aren't you worried that users might be confused regarding the command to use, depending on whether they want to run a script or a shell command?

We've been using lerna run and lerna exec for a little while. I haven't heard of anyone confused by it. I think we can mitigate that with documentation if it does become an issue.

npm/Yarn run commands are already open to cross-platform incompatibilities since you could put pwd in package.json#scripts and have the same cross-platform problems. People (including me) still think its useful regardless.

The other thing that we can do to make this useful cross-platform is to specify the $PATH the way package.json#scripts do.

From #62:

There's three options for what the $PATH should be within workspaces.

• The project's node_modules/.bin
• The workspace's node_modules/.bin
• Both (w/ workspace before project)

This is useful because people can add packages with CLIs that do things cross platform.

We've been using lerna run and lerna exec for a little while. I haven't heard of anyone confused by it. I think we can mitigate that with documentation if it does become an issue.

Fine by me, then.

The other thing that we can do to make this useful cross-platform is to specify the $PATH the way package.json#scripts do.

Ooooh, I like it, I often end up writing "env": "env" in my scripts just because I want to see the env my scripts will use. That could be an interesting use case for yarn exec (no workspace).

Ok, I'll update the document to add this.

I think we need to work through this. Yarn's own first-class flags should never require -- to be passed. If you run yarn workspace test jest -- --verbose it makes sense, but not if it is part of a Yarn command.

I wouldn't block this RFC on it though, I'm just saying I agree we need to make this work.