-
-
Notifications
You must be signed in to change notification settings - Fork 26.9k
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
Use yarn when running inside yarn workspace. #3997
Conversation
Don't we already do this? create-react-app/packages/react-scripts/scripts/eject.js Lines 227 to 256 in 47d2d94
|
@@ -224,7 +233,7 @@ inquirer | |||
} | |||
} | |||
|
|||
if (fs.existsSync(paths.yarnLockFile)) { | |||
if (fs.existsSync(paths.yarnLockFile) || isYarnAvailable()) { |
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.
If the problem is due to npm corrupting a Yarn-produced tree, this can be solved by deleting node_modules
first before re-running npm.
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 don't think it's corrupting, per-se -- it's just that if this is happening within a yarn workspace, npm can't handle it properly.
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.
But I’d like to understand what’s going on here better. Why do we run Yarn in this test even if the user created an app with npm?
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.
You mean echo yes | npm run eject
, right? We can change that to yarn. In that case, maybe you want to detect that the eject script was run with yarn and automatically use yarn for the install? That would help enforce some consistency with yarn/npm usage, but not sure what your philosophy is on that. Let me know what you want to do in this PR, not sure this PR is the appropriate place for that auto-detecting change.
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.
Hmm no, I just mean that if an app was created with npm, we should run npm on ejecting, and if it was created with Yarn, we should use Yarn.
We use the lockfile to tell if the app was created with Yarn. Is this not sufficient in this case? Why?
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.
Let's extract that into react-dev-utils
maybe and use in both places?
Or cache this in config/paths.js
.
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.
There are a bunch of places where a decision to use yarn or npm is made, probably all should be updated:
const useYarn = useNpm ? false : shouldUseYarn(); |
const useYarn = fs.existsSync(path.join(appPath, 'yarn.lock')); |
if (fs.existsSync(paths.yarnLockFile)) { |
const useYarn = fs.existsSync(paths.yarnLockFile); |
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.
The first one intentionally checks for existence of Yarn because we haven't created a project yet.
All the other ones are checking for presence of yarn.lock
. If it's committed, then the project was created with Yarn (maybe by another member of your team) so you should really install it (even if you don't have it).
I don't mind unifying all except the first one.
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.
For createReactApp.js: if a user is creating an app in a yarn workspace, they really want to be using yarn, using npm will cause issues.
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 sounds good.
@@ -49,7 +49,7 @@ const url = require('url'); | |||
const hyperquest = require('hyperquest'); | |||
const envinfo = require('envinfo'); | |||
const os = require('os'); | |||
|
|||
const monorepo = require('react-dev-utils/monorepo'); |
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.
Let's use a name likeWorkspaceUtils
so it's clearer it's a bunch of functions.
@@ -49,7 +49,7 @@ const url = require('url'); | |||
const hyperquest = require('hyperquest'); | |||
const envinfo = require('envinfo'); | |||
const os = require('os'); | |||
const monorepo = require('react-dev-utils/monorepo'); | |||
const getMonorepo = require('react-dev-utils/workspaceUtils').getMonorepo; |
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.
How about findMonorepo
? Sorry for bikeshedding on this.
Users who don't use monorepos might be confused after ejecting because how would you "get" a monorepo that doesn't exist.
Thank you! |
Use yarn when running inside yarn workspace. (facebook#3997)
* Run yarn after ejecting. * On eject, choose to run yarn instead of npm if yarn is available. * Move monorepo to react-dev-utils. * Fix lint. * Rename monorepo to workspaceUtils. * Add react-dev-utils dep for create-react-app. * getMonorepo -> findMonorepo
This reverts commit 2c34d5b.
* Run yarn after ejecting. * On eject, choose to run yarn instead of npm if yarn is available. * Move monorepo to react-dev-utils. * Fix lint. * Rename monorepo to workspaceUtils. * Add react-dev-utils dep for create-react-app. * getMonorepo -> findMonorepo
This reverts commit 2c34d5b.
Fixes this CI failure: