Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Workspaces phase 2: commands to manage workspaces #61

Merged
merged 3 commits into from
May 17, 2017
Merged

Workspaces phase 2: commands to manage workspaces #61

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4e88f14
Adds workspace command
May 5, 2017
2483a21
Update 0000-workspaces-command.md
arcanis May 16, 2017
62644fe
Update 0000-workspaces-command.md
arcanis May 16, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions accepted/0000-workspaces-command.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
- Start Date: 2017-05-04
- RFC PR:

# Summary

This document specify a new command, that can be used to execute subcommands inside a workspace projects.

# 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


# Detailed design

This RFC suggests to add the two following commands:

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

The first one will print the project directory for the package referenced by `project-name`.

The second one will be an alias for:

```
$> (cd $(yarn project <project-name> pwd) && yarn <command-name> ...)
```

# Drawbacks

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

# 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).
Copy link
Member

@bestander bestander May 5, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As if not overused already: container

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@arcanis arcanis May 16, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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