From 85747b353125aded8f28bab4970a1177ba6f815e Mon Sep 17 00:00:00 2001 From: Konstantin Raev Date: Mon, 24 Jul 2017 10:40:07 -0700 Subject: [PATCH 1/5] [WIP] Workspaces blog post Started a blog post about Yarn Workspaces --- _posts/2017-07-26-introducing-workspaces | 237 +++++++++++++++++++++++ 1 file changed, 237 insertions(+) create mode 100644 _posts/2017-07-26-introducing-workspaces diff --git a/_posts/2017-07-26-introducing-workspaces b/_posts/2017-07-26-introducing-workspaces new file mode 100644 index 000000000..0ac958a6e --- /dev/null +++ b/_posts/2017-07-26-introducing-workspaces @@ -0,0 +1,237 @@ +--- +layout : post +title : "Introducing Yarn Workspaces" +author : Konstantin Raev +author_url : "https://twitter.com/bestander_nz" +date : 2017-07-26 8:00:00 +categories : announcements +share_text : "Yarn Workspaces: the evolution of multipackage projects" +--- + +## Monorepos + +Projects tend to grow over time and occasionally some pieces of a project can be useful elsewhere. +For example, [Jest](http://facebook.github.io/jest/), being a generic test tool, gave birth to package [jest-haste-map](https://yarnpkg.com/en/package/jest-haste-map) that is now used in other projects like [metro-bunlder](https://yarnpkg.com/en/package/metro-bundler) and [kernc](https://yarnpkg.com/en/package/kernc). + +Those who tried splitting a project into multiple packages know how hard it is to make changes across multiple packages at a time. +To make their lives easier some big projects adopted a [monorepo](http://www.drmaciver.com/2016/10/why-you-should-use-a-single-repository-for-all-your-companys-projects/) approach, or multi-package repositories, which makes writing code across multiple packages much easier. + +A lot of projects that JavaScript developers are using every day are managed as monorepos: + +* [Jest](https://github.com/facebook/jest/tree/master/packages) +* [Babel](https://github.com/babel/babel/tree/7.0/packages) +* [React](https://github.com/facebook/react/tree/master/packages) +* [Vue](https://github.com/vuejs/vue/tree/dev/packages) +* [Angular](https://github.com/angular/angular/tree/master/packages) + +However, separating a piece of project into its own folder is not enough. +Testing, managing dependencies and publishing multiple packages gets complicated really fast and many of such projects [adopted](https://medium.com/@bebraw/the-case-for-monorepos-907c1361708a) tools that help working with monorepos like [Lerna](https://lernajs.io/). + +## Lerna + +Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm. +Internally it uses Yarn or npm CLI to bootstrap a project, i.e. install all third party dependencies for each package, in a nutshell Lerna calls `yarn/npm install` for each package inside the project and then creates symlinks between the packages that refer each other. + +Being a wrapper of a package manager Lerna can't manipulate the contents of node_modules efficiently: + +* Lerna calls `yarn install` multiple times for each package and this creates an overhead because each package.json is considered independent and they can't share dependencies with each other. This causes a lot of duplication for each node_modules folder that quite often use the same third-party packages. +* Lerna manually creates links between packages that refer each other after installation has finished. This introduces inconsistency inside node_modules that a package manager is not aware of, so running `yarn install` from within a package may break the meta structure that Lerna manages. + +That is why we decided that Yarn as a package manager should not ignore multi package repositories and support them natively, **starting with Yarn 0.28 Yarn has Workspaces feature**. + +## Yarn Workspaces + +Yarn Workspaces is a feature that allows one package.json file (called Workspaces Root or **root **and located at the root of the project) to refer multiple other package.json files (called Workspaces or **workspaces **located under the **root** in the folder structure) and combine them together into a single meta structure during installation. + +Having workspaces as a “native” Yarn feature allows Yarn to produce the best structure for Workspaces by removing third-party packages duplication across all workspaces and making installation much faster. +Yarn would also create the symlinks between the workspaces that depend on each other and Yarn will ensure folders consistency and correctness. + + +## Setting up Workspaces + +We should start with enabling workspaces in Yarn by running the following command. + +``` +yarn config set workspaces-experimental true +``` + +It will write line “workspaces-experimental true” to .yarnrc file in your home folder, yarn workspaces is still considered experimental while we are gathering feedback from the community. + +Let's take [Jest](http://facebook.github.io/jest/) as an example and set up Yarn Workspaces for that structure. +As a matter of fact it has already been done in [this PR](https://github.com/facebook/jest/pull/3906) and Jest is already using Yarn to bootstrap the workspaces. + +Jest's project structure is typical for an Open Source JavaScript monorepo. + +``` +` +| jest/ +| ---- package.json +| ---- packages/ +| -------- jest-matcher-utils/ +| ------------ package.json +| -------- jest-diff/ +| ------------ package.json +...` +``` + +Top level package.json defines the **root **and folders under packages folder are the packages published to npm registry, the **workspaces**. + +Following is a simplified **root** package.json that enables **workspaces** for the project and defines third-party packages that are needed for the project build and test environment. + +``` +`{ + "private": true, + "name": "jest", + "devDependencies": { + `"chalk": "^2.0.1"` + }, + "workspaces": [ + "packages/*" + ] +}` +``` + +To keep things simple I'll describe two small workspaces packages. + +1. jest-matcher-utils **workspace.** + +``` +`{ + "name": "jest-matcher-utils", + "description": "...", + "version": "20.0.3", + "license": "...", + "main": "...", + "browser": "...", + "dependencies": { + "chalk": "^1.1.3", + "pretty-format": "^20.0.3" + } +}` +``` + +2. jest-diff **workspace** that depends on jest-matcher-utils. + +``` +`{ + "name": "jest-diff", + "version": "20.0.3", + "license": "...", + "main": "...", + "browser": "...", + "dependencies": { + "chalk": "^1.1.3", + "diff": "^3.2.0", + "jest-matcher-utils": "^20.0.3", + "pretty-format": "^20.0.3" + } +}` +``` + +An approach that a wrapper like Lerna takes is to run run `yarn install` for each package.json separately and then run `yarn link` for packages that depend on each other. + +We would get a folder structure like this. + +``` +`| jest/ +| ---- node_modules/ +| -------- chalk/ +| ---- package.json +| ---- packages/ +| -------- jest-matcher-utils/ +| ------------ node_modules/ +`| ---------------- chalk/` +`| ---------------- pretty-format/ +`| ------------ package.json +| -------- jest-diff/ +| ------------ node_modules/ +``| ---------------- chalk/`` +`````| ---------------- diff/ +``````````| ---------------- jest-matcher-utils/ (symlink) -> ../jest-matcher-utils +```| ---------------- pretty-format/ +``| ------------ package.json +...` +``` + +As you see there is a redundancy of third-party dependencies. + +However, with Yarn Workspaces all node_modules are considered as one and Yarn tries to move all the packages to the root node_modules if there are no conflicts. + +``` +`| jest/ +| ---- node_modules/ +| -------- chalk/ +| -------- diff/ +| -------- pretty-format/ +`| -------- jest-matcher-utils/ (symlink) -> ../packages/jest-matcher-utils +`| ---- package.json +| ---- packages/ +| -------- jest-matcher-utils/ +| ------------ node_modules/ +`| ---------------- chalk/` +| ------------ package.json +| -------- jest-diff/ +| ------------ node_modules/ +``| ---------------- chalk/`` +| ------------ package.json +...` +``` + +Packages `diff`, `pretty-format` and symlink to `jest-matcher-utils` were hoisted to the **root** node_modules making the installation faster and smaller. +Package `chalk` could not be moved to the **root** node_modules because the **root** already depends on an different incompatible version of `chalk`. + +Both of the structures above are compatible but the latter one is more optimal while still being correct from the point of view of Node.js dependency resolution. + +If you run code inside `jest-diff` **workspace** it will be able to resolve all its dependencies: + +* require('chalk') resolves to `./node_modules/chalk` +* require('diff') resolves to `../../node_modules/diff` +* require('pretty-format') resolves to `../../node_modules/pretty-format` +* require('jest-matcher-utils') resolves to `../../node_modules/jest-matcher-utils` that is a symlink to `../packages/jest-matcher-utils` + +## Managing dependencies of Workspaces + +If you want to add/remove/upgrade a dependency of a **workspace** just change run the appropriate command inside the **workspace** folder. + +``` +$ cd packages/jest-matcher-utils/ +$ yarn add left-pad +✨ Done in 1.77s. +$ git status +modified: package.json +modified: ../../yarn.lock +``` + +Note that **workspaces** don't have yarn.lock and the **root** yarn.lock contains all the dependencies for all the **workspaces**. + +## Integrating with Lerna + +Do Yarn Workspaces make Lerna obsolete? + +Not at all. +Lerna is much more than bootstrapping a project and it has a community of users around it that fine-tuned Lerna to work for their needs. +Instead Yarn Workspaces can be integrated with Lerna. + +Starting with Lerna 2.0.0 when you pass flag [--use-workspaces](https://github.com/lerna/lerna#--use-workspaces) when running Lerna commands it will use Yarn to bootstrap the project and also it will use `package.json/workspaces` field to find the packages instead of `lerna.json/packages`. + +This is how Lerna is configured for Jest: + +``` +{ + "npmClient": "yarn", + "useWorkspaces": true +} +``` + +Jest relies on Yarn to bootstrap the project and on Lerna to run publish command. + +## What is coming next + +Yarn Workspaces is the first step of what a package manager could do for managing monorepos as they become a more common solution to code sharing. + +At the same time we don't want to put all the possible monorepo features into Yarn, we want to keep Yarn focused and lean and it means that Yarn and projects like Lerna could continue working together. + +For Yarn our next goal is to revamp `publish` feature in Yarn. +Publishing a package to the registry is a much more important step nowadays and Yarn's basic “pack and send” approach is not enough for the modern projects. + +Stay tuned. From 44ba0a3c8c6bee6d9fcd4dd6c48434aaff7eccbc Mon Sep 17 00:00:00 2001 From: Haroen Viaene Date: Wed, 26 Jul 2017 13:48:56 +0200 Subject: [PATCH 2/5] Rename 2017-07-26-introducing-workspaces to 2017-07-26-introducing-workspaces.md --- ...ntroducing-workspaces => 2017-07-26-introducing-workspaces.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename _posts/{2017-07-26-introducing-workspaces => 2017-07-26-introducing-workspaces.md} (100%) diff --git a/_posts/2017-07-26-introducing-workspaces b/_posts/2017-07-26-introducing-workspaces.md similarity index 100% rename from _posts/2017-07-26-introducing-workspaces rename to _posts/2017-07-26-introducing-workspaces.md From e281e8a75c64eb9d918ffbe183435e4e80ffcdc6 Mon Sep 17 00:00:00 2001 From: Konstantin Raev Date: Thu, 27 Jul 2017 22:20:41 -0700 Subject: [PATCH 3/5] Update 2017-07-26-introducing-workspaces.md typo fix --- _posts/2017-07-26-introducing-workspaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2017-07-26-introducing-workspaces.md b/_posts/2017-07-26-introducing-workspaces.md index 0ac958a6e..9b708d3e5 100644 --- a/_posts/2017-07-26-introducing-workspaces.md +++ b/_posts/2017-07-26-introducing-workspaces.md @@ -128,7 +128,7 @@ To keep things simple I'll describe two small workspaces packages. }` ``` -An approach that a wrapper like Lerna takes is to run run `yarn install` for each package.json separately and then run `yarn link` for packages that depend on each other. +An approach that a wrapper like Lerna takes is to run `yarn install` for each package.json separately and then run `yarn link` for packages that depend on each other. We would get a folder structure like this. From dd927a055cd4a8d12319ea5dd130e0eea2781a52 Mon Sep 17 00:00:00 2001 From: Konstantin Raev Date: Thu, 3 Aug 2017 10:58:52 -0700 Subject: [PATCH 4/5] Update 2017-07-26-introducing-workspaces.md incorporated feedback --- _posts/2017-07-26-introducing-workspaces.md | 150 +++++++++----------- 1 file changed, 71 insertions(+), 79 deletions(-) diff --git a/_posts/2017-07-26-introducing-workspaces.md b/_posts/2017-07-26-introducing-workspaces.md index 9b708d3e5..32fda1b70 100644 --- a/_posts/2017-07-26-introducing-workspaces.md +++ b/_posts/2017-07-26-introducing-workspaces.md @@ -1,6 +1,6 @@ --- layout : post -title : "Introducing Yarn Workspaces" +title : "Workspaces in Yarn" author : Konstantin Raev author_url : "https://twitter.com/bestander_nz" date : 2017-07-26 8:00:00 @@ -8,62 +8,50 @@ categories : announcements share_text : "Yarn Workspaces: the evolution of multipackage projects" --- -## Monorepos +# Workspaces in Yarn -Projects tend to grow over time and occasionally some pieces of a project can be useful elsewhere. -For example, [Jest](http://facebook.github.io/jest/), being a generic test tool, gave birth to package [jest-haste-map](https://yarnpkg.com/en/package/jest-haste-map) that is now used in other projects like [metro-bunlder](https://yarnpkg.com/en/package/metro-bundler) and [kernc](https://yarnpkg.com/en/package/kernc). +## Monorepos -Those who tried splitting a project into multiple packages know how hard it is to make changes across multiple packages at a time. -To make their lives easier some big projects adopted a [monorepo](http://www.drmaciver.com/2016/10/why-you-should-use-a-single-repository-for-all-your-companys-projects/) approach, or multi-package repositories, which makes writing code across multiple packages much easier. +Projects tend to grow over time, and, occasionally, some pieces of a project can be useful elsewhere in other projects. For example, [Jest](http://facebook.github.io/jest/), being a generic testing tool, gave birth to many packages, one of them is [jest-snapshot](https://yarnpkg.com/en/package/jest-snapshot) that is now used in other projects like [snapguidist](https://yarnpkg.com/en/package/snapguidist) and [chai-jest-snapshot](https://yarnpkg.com/en/package/chai-jest-snapshot). -A lot of projects that JavaScript developers are using every day are managed as monorepos: +Those who have [tried splitting a project into multiple packages](https://youtu.be/PvabBs_utr8?t=16m24s) know how hard it is to make changes across multiple packages at one time. To make the process easier, some big projects adopted a [monorepo](http://www.drmaciver.com/2016/10/why-you-should-use-a-single-repository-for-all-your-companys-projects/) approach, or multi-package repositories, which reduces the burden of writing code across packages. -* [Jest](https://github.com/facebook/jest/tree/master/packages) -* [Babel](https://github.com/babel/babel/tree/7.0/packages) -* [React](https://github.com/facebook/react/tree/master/packages) -* [Vue](https://github.com/vuejs/vue/tree/dev/packages) -* [Angular](https://github.com/angular/angular/tree/master/packages) +Several projects used every day by JavaScript developers are managed as monorepos: [Babel](https://github.com/babel/babel/tree/7.0/packages), [React](https://github.com/facebook/react/tree/master/packages), [Jest](https://github.com/facebook/jest/tree/master/packages), [Vue](https://github.com/vuejs/vue/tree/dev/packages), [Angular](https://github.com/angular/angular/tree/master/packages). -However, separating a piece of project into its own folder is not enough. -Testing, managing dependencies and publishing multiple packages gets complicated really fast and many of such projects [adopted](https://medium.com/@bebraw/the-case-for-monorepos-907c1361708a) tools that help working with monorepos like [Lerna](https://lernajs.io/). +However, separating pieces of projects into their own folders is sometimes not enough. Testing, managing dependencies, and publishing multiple packages quickly gets complicated and many such projects [adopt](https://medium.com/@bebraw/the-case-for-monorepos-907c1361708a) tools such as [Lerna](https://lernajs.io/) to make working with monorepos easier. ## Lerna -Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm. -Internally it uses Yarn or npm CLI to bootstrap a project, i.e. install all third party dependencies for each package, in a nutshell Lerna calls `yarn/npm install` for each package inside the project and then creates symlinks between the packages that refer each other. - -Being a wrapper of a package manager Lerna can't manipulate the contents of node_modules efficiently: +Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm. Internally it uses [Yarn](https://code.facebook.com/posts/1840075619545360) or the npm CLI to bootstrap (i.e. install all third party dependencies for each package) a project. In a nutshell, Lerna calls `yarn/npm install` for each package inside the project and then creates symlinks between the packages that refer each other. -* Lerna calls `yarn install` multiple times for each package and this creates an overhead because each package.json is considered independent and they can't share dependencies with each other. This causes a lot of duplication for each node_modules folder that quite often use the same third-party packages. -* Lerna manually creates links between packages that refer each other after installation has finished. This introduces inconsistency inside node_modules that a package manager is not aware of, so running `yarn install` from within a package may break the meta structure that Lerna manages. +Being a wrapper of a package manager, Lerna can't manipulate the contents of node_modules efficiently: -That is why we decided that Yarn as a package manager should not ignore multi package repositories and support them natively, **starting with Yarn 0.28 Yarn has Workspaces feature**. +* Lerna calls `yarn install` multiple times for each package which creates overhead because each `package.json` is considered independent and they can't share dependencies with each other. This causes a lot of duplication for each node_modules folder which quite often use the same third-party packages. +* Lerna manually creates links between packages that refer each other after installation has finished. This introduces inconsistency inside node_modules that a package manager may not be aware of, so running `yarn install` from within a package may break the meta structure that Lerna manages. -## Yarn Workspaces +Issues such as these convinced us, as package manager developers, that we should support multi-package repositories directly in Yarn. **Starting with [Yarn 0.28,](https://yarnpkg.com/en/docs/install) we're excited to share that we support such repositories under the Workspaces feature**. -Yarn Workspaces is a feature that allows one package.json file (called Workspaces Root or **root **and located at the root of the project) to refer multiple other package.json files (called Workspaces or **workspaces **located under the **root** in the folder structure) and combine them together into a single meta structure during installation. +## Introducing Yarn Workspaces -Having workspaces as a “native” Yarn feature allows Yarn to produce the best structure for Workspaces by removing third-party packages duplication across all workspaces and making installation much faster. -Yarn would also create the symlinks between the workspaces that depend on each other and Yarn will ensure folders consistency and correctness. +Yarn Workspaces is a feature that allows users to install dependencies from multiple package.json files in subfolders of a single root package.json file, all in one go. +Making Workspaces native to Yarn enables faster, lighter installation by preventing package duplication across Workspaces. Yarn can also create symlinks between Workspaces that depend on each other, and will ensure the consistency and correctness of all directories. ## Setting up Workspaces -We should start with enabling workspaces in Yarn by running the following command. +To get started, users must enable Workspaces in Yarn by running the following command: ``` yarn config set workspaces-experimental true ``` -It will write line “workspaces-experimental true” to .yarnrc file in your home folder, yarn workspaces is still considered experimental while we are gathering feedback from the community. +It will add `workspaces-experimental true` to the `.yarnrc` file in your OS home folder. Yarn Workspaces is still considered experimental while we gather feedback from the community. -Let's take [Jest](http://facebook.github.io/jest/) as an example and set up Yarn Workspaces for that structure. -As a matter of fact it has already been done in [this PR](https://github.com/facebook/jest/pull/3906) and Jest is already using Yarn to bootstrap the workspaces. +Let's take [Jest](http://facebook.github.io/jest/) as an example and set Yarn Workspaces up for that structure. As a matter of fact, it has already been [done in a PR](https://github.com/facebook/jest/pull/3906), and Jest has been using Yarn to bootstrap its packages for a while. Jest's project structure is typical for an Open Source JavaScript monorepo. ``` -` | jest/ | ---- package.json | ---- packages/ @@ -71,32 +59,34 @@ Jest's project structure is typical for an Open Source JavaScript monorepo. | ------------ package.json | -------- jest-diff/ | ------------ package.json -...` +... ``` -Top level package.json defines the **root **and folders under packages folder are the packages published to npm registry, the **workspaces**. +The top-level `package.json` defines the root of the project, and folders with other package.json files are the Workspaces. +Workspaces usually are published to a registry like npm. +While the the root is not supposed to be consumed as a package, it usually contains the glue code or business specific code that is not useful for sharing with other projects, that is why we mark it as “private”. -Following is a simplified **root** package.json that enables **workspaces** for the project and defines third-party packages that are needed for the project build and test environment. +The following example is a simplified root `package.json` that enables Workspaces for the project and defines third-party packages needed for the project build and test environment. ``` -`{ +{ "private": true, "name": "jest", "devDependencies": { - `"chalk": "^2.0.1"` + "chalk": "^2.0.1" }, "workspaces": [ "packages/*" ] -}` +} ``` -To keep things simple I'll describe two small workspaces packages. +To keep things simple I'll describe two small Workspaces packages: -1. jest-matcher-utils **workspace.** +1. jest-matcher-utils Workspace: ``` -`{ +{ "name": "jest-matcher-utils", "description": "...", "version": "20.0.3", @@ -107,13 +97,13 @@ To keep things simple I'll describe two small workspaces packages. "chalk": "^1.1.3", "pretty-format": "^20.0.3" } -}` +} ``` -2. jest-diff **workspace** that depends on jest-matcher-utils. +2. jest-diff Workspace that depends on jest-matcher-utils: ``` -`{ +{ "name": "jest-diff", "version": "20.0.3", "license": "...", @@ -125,64 +115,65 @@ To keep things simple I'll describe two small workspaces packages. "jest-matcher-utils": "^20.0.3", "pretty-format": "^20.0.3" } -}` +} ``` -An approach that a wrapper like Lerna takes is to run `yarn install` for each package.json separately and then run `yarn link` for packages that depend on each other. +A wrapper like Lerna would first run `yarn install` for each `package.json` separately and then run `yarn link` for packages that depend on each other. -We would get a folder structure like this. +If we used that approach, we would get a folder structure like the following: ``` -`| jest/ +| jest/ | ---- node_modules/ | -------- chalk/ | ---- package.json | ---- packages/ | -------- jest-matcher-utils/ | ------------ node_modules/ -`| ---------------- chalk/` -`| ---------------- pretty-format/ -`| ------------ package.json +| ---------------- chalk/ +| ---------------- pretty-format/ +| ------------ package.json | -------- jest-diff/ | ------------ node_modules/ -``| ---------------- chalk/`` -`````| ---------------- diff/ -``````````| ---------------- jest-matcher-utils/ (symlink) -> ../jest-matcher-utils -```| ---------------- pretty-format/ -``| ------------ package.json -...` +| ---------------- chalk/ +| ---------------- diff/ +| ---------------- jest-matcher-utils/ (symlink) -> ../jest-matcher-utils +| ---------------- pretty-format/ +| ------------ package.json +... ``` -As you see there is a redundancy of third-party dependencies. +As you see, there is a redundancy of third-party dependencies. -However, with Yarn Workspaces all node_modules are considered as one and Yarn tries to move all the packages to the root node_modules if there are no conflicts. +With Workspaces enabled, Yarn can produce a much more optimized dependency structure and when you run the usual `yarn install` anywhere in the project you'll get the following node_modules. ``` -`| jest/ +| jest/ | ---- node_modules/ | -------- chalk/ | -------- diff/ | -------- pretty-format/ -`| -------- jest-matcher-utils/ (symlink) -> ../packages/jest-matcher-utils -`| ---- package.json +| -------- jest-matcher-utils/ (symlink) -> ../packages/jest-matcher-utils +| ---- package.json | ---- packages/ | -------- jest-matcher-utils/ | ------------ node_modules/ -`| ---------------- chalk/` +| ---------------- chalk/` | ------------ package.json | -------- jest-diff/ | ------------ node_modules/ -``| ---------------- chalk/`` +| ---------------- chalk/ | ------------ package.json -...` +... ``` -Packages `diff`, `pretty-format` and symlink to `jest-matcher-utils` were hoisted to the **root** node_modules making the installation faster and smaller. -Package `chalk` could not be moved to the **root** node_modules because the **root** already depends on an different incompatible version of `chalk`. +Packages like `diff`, `pretty-format` and the symlink to `jest-matcher-utils` were hoisted to the root node_modules directory, making the installation faster and smaller. The package `chalk` however could not be moved to the root because the root already depends on an different, incompatible version of `chalk`. + +Both of the structures above are compatible, but the latter is more optimal while still being correct regarding the Node.js module resolution logic. -Both of the structures above are compatible but the latter one is more optimal while still being correct from the point of view of Node.js dependency resolution. +For avid Lerna users this is similar to bootstrapping code via the `--hoist` flag. -If you run code inside `jest-diff` **workspace** it will be able to resolve all its dependencies: +If you run code inside the `jest-diff` Workspace, it will be able to resolve all its dependencies: * require('chalk') resolves to `./node_modules/chalk` * require('diff') resolves to `../../node_modules/diff` @@ -191,7 +182,7 @@ If you run code inside `jest-diff` **workspace** it will be able to resolve all ## Managing dependencies of Workspaces -If you want to add/remove/upgrade a dependency of a **workspace** just change run the appropriate command inside the **workspace** folder. +If you want to modify a dependency of a Workspace, just run the appropriate command inside the Workspace folder: ``` $ cd packages/jest-matcher-utils/ @@ -202,17 +193,18 @@ modified: package.json modified: ../../yarn.lock ``` -Note that **workspaces** don't have yarn.lock and the **root** yarn.lock contains all the dependencies for all the **workspaces**. +Note that Workspaces don't have their own yarn.lock files, and the root yarn.lock contains all the dependencies for all the Workspaces. +When you want to change a dependency inside a Workspace, the root yarn.lock will be changed as well as the Workspace's package.json. ## Integrating with Lerna Do Yarn Workspaces make Lerna obsolete? -Not at all. -Lerna is much more than bootstrapping a project and it has a community of users around it that fine-tuned Lerna to work for their needs. -Instead Yarn Workspaces can be integrated with Lerna. +Not at all. Yarn Workspaces are easily integrated with Lerna -Starting with Lerna 2.0.0 when you pass flag [--use-workspaces](https://github.com/lerna/lerna#--use-workspaces) when running Lerna commands it will use Yarn to bootstrap the project and also it will use `package.json/workspaces` field to find the packages instead of `lerna.json/packages`. +Lerna provides a lot more than just bootstrapping a project and it has a community of users around it that have fine-tuned Lerna for their needs. + +Starting with Lerna 2.0.0, when you pass the flag [--use-workspaces](https://github.com/lerna/lerna#--use-workspaces) when running Lerna commands, it will use Yarn to bootstrap the project and also it will use `package.json/workspaces` field to find the packages instead of `lerna.json/packages`. This is how Lerna is configured for Jest: @@ -223,15 +215,15 @@ This is how Lerna is configured for Jest: } ``` -Jest relies on Yarn to bootstrap the project and on Lerna to run publish command. +Jest relies on Yarn to bootstrap the project, and on Lerna for running the publish command(s). -## What is coming next +## What is next? Yarn Workspaces is the first step of what a package manager could do for managing monorepos as they become a more common solution to code sharing. -At the same time we don't want to put all the possible monorepo features into Yarn, we want to keep Yarn focused and lean and it means that Yarn and projects like Lerna could continue working together. +At the same time we don't want to put all the possible monorepo features into Yarn. We want to keep Yarn focused and lean, and this means that Yarn and projects like Lerna will continue working together. + +Our next goal is to finalize Yarn 1.0, which is meant to summarize the work we have done on Yarn over the past year, and recognizing how reliable Yarn has become. We'll also share our thoughts on what we'd like to build next for Yarn then. -For Yarn our next goal is to revamp `publish` feature in Yarn. -Publishing a package to the registry is a much more important step nowadays and Yarn's basic “pack and send” approach is not enough for the modern projects. +Stay tuned. -Stay tuned. From 328e50111eaedef16cd7aba37355b63bdeb70bd1 Mon Sep 17 00:00:00 2001 From: Konstantin Raev Date: Thu, 3 Aug 2017 10:59:30 -0700 Subject: [PATCH 5/5] Update 2017-07-26-introducing-workspaces.md --- _posts/2017-07-26-introducing-workspaces.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/2017-07-26-introducing-workspaces.md b/_posts/2017-07-26-introducing-workspaces.md index 32fda1b70..c884817c5 100644 --- a/_posts/2017-07-26-introducing-workspaces.md +++ b/_posts/2017-07-26-introducing-workspaces.md @@ -3,7 +3,7 @@ layout : post title : "Workspaces in Yarn" author : Konstantin Raev author_url : "https://twitter.com/bestander_nz" -date : 2017-07-26 8:00:00 +date : 2017-08-02 8:00:00 categories : announcements share_text : "Yarn Workspaces: the evolution of multipackage projects" ---