-
Notifications
You must be signed in to change notification settings - Fork 682
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.
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
Yarn & Babel 7 #753
Yarn & Babel 7 #753
Conversation
This pull request is automatically deployed with Now. |
Regarding CircleCI config: https://circleci.com/docs/2.0/yarn/ seems pretty straightforward. I know that the cache parts are pretty weird, but fortunately this Yarn doc has some stuff you can cut and paste right over what we have today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am so impressed at how small this changeset is, given the nature of the change. Could you please post some stats on the difference in final bundle sizes, build times, etc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial once-over review. Have a few questions about all the dependencies being removed. Happy to see them go if they are not needed but wanted to get some more context on the changes.
Also can we add a .yarnrc file? I think the yarn-path would be good to set
but that ^ brings up a question, what is the preferred way of installing yarn? will we run into yarn dependency differences if we all have different local versions?
i'd recommend the yarn version be set in the engine field so we at least have a place to start from when debugging.
"clean:dist": "npx lerna run clean", | ||
"build": "yarn workspaces run build", | ||
"build:dev": "yarn workspaces run build:dev", | ||
"clean:all": "yarn workspaces run clean && rimraf ./node_modules", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would we also want to clear the yarn cache?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I have more questions around when to use yarn workspaces
and when to leverage our use of lerna bootstrap
to install all of our package dependencies, and running commands like lerna run clean
to remove all the package node_modules folders for us. Isn't lerna our monorepo package manager? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A main objective of this change is to stop using lerna
for most of our monorepo tasks—especially for install, build, and clean operations. The goal is to have each package describe its own dependencies accurately.
Run yarn
from the root directory and it will install all dependencies for the monorepo. Similarly, yarn build:dev
and yarn:clean
from the root will use workspaces
to run that command in each workspace. It should be faster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good, i think from our discussion I'd like to remove lerna as a tool then if we are going to switch to using these workspaces and clear it out of our dependencies.
I left a few comments but I was also unable to run the
Do I need to do anything other than |
There are still quite a few references to |
Yes, you need to build |
], | ||
"npmClient": "npm" | ||
"npmClient": "yarn", | ||
"useWorkspaces": true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we just remove this file now that we are going to use yarn workspaces?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like lerna.json is obsolete now, same question as above, can we remove this file now? It looks like you removed lerna from everywhere so far but this file. We probably want to make that change as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a couple more comments. I am ready to sign off on this when the comments I left are addressed and the now.sh is fixed. For the now.sh deploy error, a nuclear fix may be to add yarn --ignore-engines
but I think that's not ideal. I didn't see a good fix for this online as of yet.
@sharkySharks Thanks for taking another look. Here are remaining tasks:
According to this issue, |
I don't want to block the review process. My comments have been addressed, now.sh just needs to be debugged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This works great for me and +15,301 −39,645
💪
* Don't check in a big change to `package-lock.json`, and don't check in any `package-lock.json` files but the root one. | ||
* Make sure to run `npm run prettier` and `npm run lint` before any commit you intend to push. You may want to set up a [Git hook] for this. | ||
* Don't run `npm install`! Since this project has been configured with [Yarn Workspaces][], run `yarn install` to properly install, hoist, and cross-link dependencies. | ||
* Don't check in `package-lock.json`. There is only one lockfile, `yarn.lock`, and it's in the root directory. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
Description =========== When migrating from npm to yarn, we tried to spread devDependencies across the packages instead of centralizing them at root. Unfortunately, we omitted a dependency that _needs_ to be at root so its CLI is available in scripts, [coveralls](https://github.com/nickmerwin/node-coveralls#readme). Missing this dependency caused every build after the merge of #753 and all we need to do is add it back: `yarn add -W --dev coveralls`. DangerCI has a transitive dependency on an outdated version of its GitHub client library, but the semver dependency in DangerCI allows updates, so we ran `yarn upgrade danger` and saw an Octokit update appear in yarn.lock.
Description =========== When migrating from npm to yarn, we tried to spread devDependencies across the packages instead of centralizing them at root. Unfortunately, we omitted a dependency that _needs_ to be at root so its CLI is available in scripts, [coveralls](https://github.com/nickmerwin/node-coveralls#readme). Missing this dependency caused every build after the merge of #753 and all we need to do is add it back: `yarn add -W --dev coveralls`. DangerCI has a transitive dependency on an outdated version of its GitHub client library, but the semver dependency in DangerCI allows updates, so we ran `yarn upgrade danger` and saw an Octokit update appear in yarn.lock.
This PR is a:
Summary
When this pull request is merged, it will migrate from NPM to Yarn. In the process, it will also upgrade the repo to Babel
7.2.0
.Additional Information
Getting Started
Motivation
Package management is currently one of our biggest pain points. Installing and building packages is slow, and our current workflow requires us to reinstall
node_modules
and rebuild every package on a regular basis. These operations should be faster and used less frequently.Furthermore, as a monorepo,
pwa-studio
has a complex dependency tree. Our packages share a number of dependencies, and some of them depend on other packages within the monorepo. We currently uselerna
to hoist dependencies into the monorepo root, butlerna
isn't particularly fast. Worse, each package in this repository should list its own dependencies accurately, but we've blurred the lines betweendependencies
anddevDependencies
just to enablelerna
to inform us about mismatched dependencies. As a result, most of ourpackage.json
files are missing dependencies, and our rootpackage.json
file contains unused dependencies.Yarn
Fortunately,
yarn
can help us solve both problems.Hoisting
Yarn Workspaces directly address our monorepo problems. When
pwa-studio
is configured as a monorepo withworkspaces
, runningyarn install
from the root will install, hoist, and dedupe the dependencies listed in each workspace'spackage.json
file, plus any dependencies listed in the rootpackage.json
file. We no longer need to manually update the root when a dependency changes within a workspace.Workspaces also simplify our package scripts:
yarn workspaces run clean
clean
script within each packageyarn workspace @magento/venia-concept run watch
watch
script withinpackages/venia-concept
Speed
But most importantly,
yarn
is fast.clean
install
build