version :Yarn 2.x
从Yarn 1.0开始，工作区是一种新的设置包体系结构的方法。它允许您设置多个软件包，这样您只需运行yarn install一次就可以在一次操作中安装所有软件包。
你为什么要这么做？
-
您的依赖关系可以链接在一起，这意味着您的工作区可以相互依赖，同时始终使用可用的最新代码。这也是比yarn link更好的机制，因为它只影响您的工作区树，而不是整个系统。
-
所有的项目依赖项都将被安装在一起，给yarn更多的空间来更好地优化它们。
-
Yarn将为每个项目使用一个单独的锁文件，而不是一个不同的锁文件，这意味着更少的冲突和更容易的审查。
如何使用它？
在package.json中添加以下内容。从现在开始，我们将这个目录称为“workspace root”：
package.json
{
"private": true,
"workspaces": ["workspace-a", "workspace-b"]
}
注意，private:true是必需的！工作区不是要发布的，所以我们添加了这个安全措施，以确保不会意外地暴露它们。
创建此文件后，创建两个名为workspace-a和workspace-b的新子文件夹。在每个子文件夹中，创建另一个子文件package.json包含以下内容的文件：
workspace-a/package.json:
{
"name": "workspace-a",
"version": "1.0.0",
"dependencies": {
"cross-env": "5.0.5"
}
}
workspace-b/package.json:
{
"name": "workspace-b",
"version": "1.0.0",
"dependencies": {
"cross-env": "5.0.5",
"workspace-a": "1.0.0"
}
}
最后，在某个地方运行yarn install，最好是在工作区根目录中。如果你现在有一个类似的文件，你应该有一个类似的文件结构：
/package.json
/yarn.lock
/node_modules
/node_modules/cross-env
/node_modules/workspace-a -> /workspace-a
/workspace-a/package.json
/workspace-b/package.json
注意：不要寻找/node_ modules/workspace-b。除非其他软件包将其用作依赖项，否则它不会存在。
就这样！从位于workspace-b中的文件中请求workspace-a将使用当前位于项目内部的确切代码，而不是npm上发布的代码，并且cross-env包已被正确地删除并放在项目的根目录，供workspace-a和workspace-b使用。
请注意，通过符号链接，/workspace-a别名为/node_ modules/workspace-a。这是一个技巧，让你require这个包，好像它是一个正常的node_ modules包！您还需要知道/workspace-a/package.json name字段，而不是文件夹名称。这意味着如果/workspace-a/package.json name字段为“pkg-a”，别名如下：/node_modules/pkg-a->/workspace-a，您可以从/workspace-a导入代码，const pkgA=require（“pkg-a”）；（也可以从“pkg-a”导入pkgA）。
与Lerna相比如何？
Yarn的工作区是像Lerna这样的工具可以（也可以做！）使用。他们永远不会试图支持Lerna提供的高级功能，但是通过实现解析的核心逻辑和在Yarn内部链接步骤，我们希望能够实现新的用途并提高性能。
提示与技巧
-
“工作区”字段是一个数组，其中包含指向每个工作区的路径。因为跟踪每一个可能很乏味，所以这个领域也接受glob模式！例如，Babel通过一个packages/*指令引用他们的所有包。
-
工作区足够稳定，可以在大型应用程序中使用，不会改变常规安装的工作方式，但是如果您认为它们破坏了某些东西，可以通过在Yarnrc文件中添加以下行来禁用它们：
workspaces-experimental false
-
如果只对单个工作区进行更改，请使用–focus从注册表快速安装同级依赖项，而不是从头开始构建所有这些依赖项。
限制和注意事项
您的工作区和您的用户将得到的包布局将有所不同（工作区依赖关系将提升到更高的文件系统层次结构中）。由于提升过程没有标准化，对这种布局的假设已经很危险了，所以理论上这里没有什么新的东西。如果遇到问题，请尝试使用nohoist 选项
在上面的例子中，如果workspace-b依赖于与workspace-a中引用的版本不同的版本package.json，依赖项将从npm安装，而不是从本地文件系统链接。这是因为有些包实际上需要使用以前的版本来构建新版本（Babel就是其中之一）。
在工作区中发布包时要小心。如果您正在准备下一个版本，并且决定使用新的依赖项，但忘记在package.json文件中声明它，如果另一个包已将该依赖项下载到工作区根目录中，则您的测试仍可能在本地通过。但是，对于从注册表中提取它的用户来说，它将被破坏，因为依赖项列表现在不完整，因此他们无法下载新的依赖项。目前在这种情况下无法抛出警告。
就文件夹层次结构而言，工作区必须是工作区根目录的后代。您不能也不能引用位于此文件系统层次结构之外的工作区。
此时不支持嵌套工作区。
