Workspaces phase 2: commands to manage workspaces #61

arcanis · 2017-05-05T15:17:01Z

No description provided.

bestander · 2017-05-05T15:31:34Z

accepted/0000-workspaces-command.md

+
+# Alternatives
+
+- Is `yarn project` a good name? I considered `yarn workspace`, but we're not operating on the workspace itself, just its projects. I feel like a `yarn workspace` command should only affect the root package.json (the one who contains the `workspaces` directive).


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, ...

jamiebuilds · 2017-05-05T18:06:09Z

See yarn exec and yarn workspaces exec / yarn ws exec in: #62

bestander · 2017-05-11T14:51:55Z

accepted/0000-workspaces-command.md

+
+# Motivation
+
+With the addition of workspaces, it will become handy to be able to execute commands inside other projects than the one in the current directory.


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.

arcanis · 2017-05-16T10:36:11Z

Matching implementation: yarnpkg/yarn#3365. Still a work-in-progress, but it seems to work relatively well. I'll clean it this afternoon, but still happy to hear feedbacks!

@thejameskyle I think the command described in this RFC is very similar to the one you described in your own RFC. Do you want to discuss here this specific part of the Workspace feature? I think we can reasonably also talk about your idea of yarn workspace exec, which share a similar scope 🙂

jamiebuilds · 2017-05-16T10:54:17Z

accepted/0000-workspaces-command.md

+
+```
+$> yarn workspace <project-name> pwd
+$> yarn workspace <project-name> <command-name> ...


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)

project-level workspace-level

yarn <command/run-script> yarn workspace <name> <command/run-script>

yarn run <run-script> yarn workspace <name> run <run-script>

yarn exec <system-command> yarn workspace <name> exec <system-command>

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.

cpojer · 2017-05-16T15:42:02Z

accepted/0000-workspaces-command.md

+
+# Drawbacks
+
+- We will still have the issue of requiring the `--` separator to forward any command line option (`yarn workspace test install -- --production`). It's an important issue, something we really should tackle sooner than later.


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.

bestander

Great work, guys.
Good to be merged, @thejameskyle, @cpojer?

jamiebuilds · 2017-05-17T00:07:43Z

Do we want to limit it to valid set of sub-commands that Yarn will run inside workspaces?

arcanis · 2017-05-17T09:47:22Z

Implementation-wise I don't think it's necessary, and I'd prefer to avoid maintaining a whitelist. Some commands will make little sense in a workspace context, sure, but who knows, maybe people will come up with some creative uses.

Ok! I'll merge this this afternoon if everyone's ok with this, and finish the PR in the train 👍

jardakotesovec · 2017-06-02T08:42:45Z

Its not clear to me if is possible to install only subset of workspaces. yarn install in root folder install all workspaces. But in some cases (deployment of individual workspaces) we would like to install one or few of the workspaces, but still that it would install to the node_modules in top folder and would be merged with top package.json.

Could be such use case considered?

arcanis · 2017-06-02T09:00:34Z

I think we eventually will, but right now installing a worktree will install the dependencies for all the workspaces at once.

Adds workspace command

4e88f14

arcanis requested review from cpojer and bestander May 5, 2017 15:17

bestander mentioned this pull request May 5, 2017

Workspaces issue progress yarnpkg/yarn#3294

Closed

22 tasks

bestander reviewed May 5, 2017

View reviewed changes

bestander reviewed May 11, 2017

View reviewed changes

Update 0000-workspaces-command.md

2483a21

jamiebuilds reviewed May 16, 2017

View reviewed changes

Update 0000-workspaces-command.md

62644fe

cpojer reviewed May 16, 2017

View reviewed changes

bestander approved these changes May 16, 2017

View reviewed changes

arcanis merged commit ec136a6 into yarnpkg:master May 17, 2017

arcanis deleted the workspace-command branch May 17, 2017 12:51

bestander changed the title ~~Adds workspace command~~ Workspaces phase 2: commands to manage workspaces May 18, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Workspaces phase 2: commands to manage workspaces #61

Workspaces phase 2: commands to manage workspaces #61

arcanis commented May 5, 2017

bestander May 5, 2017 •

edited

Loading

ghost May 11, 2017

bestander May 11, 2017

arcanis May 16, 2017 •

edited

Loading

jamiebuilds commented May 5, 2017

bestander May 11, 2017

arcanis May 16, 2017

arcanis commented May 16, 2017 •

edited

Loading

jamiebuilds May 16, 2017 •

edited

Loading

arcanis May 16, 2017 •

edited

Loading

jamiebuilds May 16, 2017

jamiebuilds May 16, 2017 •

edited

Loading

arcanis May 16, 2017

cpojer May 16, 2017

cpojer May 16, 2017

bestander left a comment

jamiebuilds commented May 17, 2017

arcanis commented May 17, 2017

jardakotesovec commented Jun 2, 2017

arcanis commented Jun 2, 2017


		# Alternatives

		- Is `yarn project` a good name? I considered `yarn workspace`, but we're not operating on the workspace itself, just its projects. I feel like a `yarn workspace` command should only affect the root package.json (the one who contains the `workspaces` directive).


		# Motivation

		With the addition of workspaces, it will become handy to be able to execute commands inside other projects than the one in the current directory.

project-level	workspace-level
`yarn <command/run-script>`	`yarn workspace <name> <command/run-script>`
`yarn run <run-script>`	`yarn workspace <name> run <run-script>`
`yarn exec <system-command>`	`yarn workspace <name> exec <system-command>`


		# Drawbacks

		- We will still have the issue of requiring the `--` separator to forward any command line option (`yarn workspace test install -- --production`). It's an important issue, something we really should tackle sooner than later.

Workspaces phase 2: commands to manage workspaces #61

Workspaces phase 2: commands to manage workspaces #61

Conversation

arcanis commented May 5, 2017

bestander May 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arcanis May 16, 2017 • edited Loading

Choose a reason for hiding this comment

jamiebuilds commented May 5, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arcanis commented May 16, 2017 • edited Loading

jamiebuilds May 16, 2017 • edited Loading

Choose a reason for hiding this comment

arcanis May 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamiebuilds May 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bestander left a comment

Choose a reason for hiding this comment

jamiebuilds commented May 17, 2017

arcanis commented May 17, 2017

jardakotesovec commented Jun 2, 2017

arcanis commented Jun 2, 2017

bestander May 5, 2017 •

edited

Loading

arcanis May 16, 2017 •

edited

Loading

arcanis commented May 16, 2017 •

edited

Loading

jamiebuilds May 16, 2017 •

edited

Loading

arcanis May 16, 2017 •

edited

Loading

jamiebuilds May 16, 2017 •

edited

Loading