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.

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

Merged
merged 7 commits into from
Feb 10, 2018

Conversation

bradfordlemley
Copy link
Contributor

@bradfordlemley bradfordlemley commented Feb 8, 2018

Fixes this CI failure:

TypeError: Cannot read property 'loose' of undefined (While processing preset: "/tmp/tmp.XQoCgXQtTQ/yarn-ws/node_modules/babel-preset-react-app/index.js")

@bradfordlemley bradfordlemley changed the title Run yarn after ejecting in e2e-monorepo. Fix for e2e-monorepos failure. Feb 8, 2018
@Timer
Copy link
Contributor

Timer commented Feb 9, 2018

Don't we already do this?

if (fs.existsSync(paths.yarnLockFile)) {
const windowsCmdFilePath = path.join(
appPath,
'node_modules',
'.bin',
'react-scripts.cmd'
);
let windowsCmdFileContent;
if (process.platform === 'win32') {
// https://github.com/facebook/create-react-app/pull/3806#issuecomment-357781035
// Yarn is diligent about cleaning up after itself, but this causes the react-scripts.cmd file
// to be deleted while it is running. This trips Windows up after the eject completes.
// We'll read the batch file and later "write it back" to match npm behavior.
try {
windowsCmdFileContent = fs.readFileSync(windowsCmdFilePath);
} catch (err) {
// If this fails we're not worse off than if we didn't try to fix it.
}
}
console.log(cyan('Running yarn...'));
spawnSync('yarnpkg', ['--cwd', process.cwd()], { stdio: 'inherit' });
if (windowsCmdFileContent && !fs.existsSync(windowsCmdFilePath)) {
try {
fs.writeFileSync(windowsCmdFilePath, windowsCmdFileContent);
} catch (err) {
// If this fails we're not worse off than if we didn't try to fix it.
}
}

@@ -224,7 +233,7 @@ inquirer
}
}

if (fs.existsSync(paths.yarnLockFile)) {
if (fs.existsSync(paths.yarnLockFile) || isYarnAvailable()) {
Copy link
Contributor

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.

Copy link
Contributor Author

@bradfordlemley bradfordlemley Feb 9, 2018

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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);

Copy link
Contributor

@gaearon gaearon Feb 9, 2018

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.

Copy link
Contributor Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

This sounds good.

@bradfordlemley bradfordlemley changed the title Fix for e2e-monorepos failure. Use yarn when running inside yarn workspace. Feb 9, 2018
@@ -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');
Copy link
Contributor

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;
Copy link
Contributor

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.

@gaearon gaearon added this to the 2.0.0 milestone Feb 10, 2018
@gaearon gaearon merged commit 2c34d5b into facebook:next Feb 10, 2018
@gaearon
Copy link
Contributor

gaearon commented Feb 10, 2018

Thank you!

tvalentius added a commit to tvalentius/create-react-app that referenced this pull request Feb 10, 2018
Use yarn when running inside yarn workspace. (facebook#3997)
akstuhl pushed a commit to akstuhl/create-react-app that referenced this pull request Mar 15, 2018
* 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
Timer added a commit to Timer/create-react-app that referenced this pull request Sep 18, 2018
zmitry pushed a commit to zmitry/create-react-app that referenced this pull request Sep 30, 2018
* 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
zmitry pushed a commit to zmitry/create-react-app that referenced this pull request Sep 30, 2018
bradfordlemley added a commit to bradfordlemley/create-react-app that referenced this pull request Oct 11, 2018
bradfordlemley added a commit to bradfordlemley/create-react-app that referenced this pull request Nov 1, 2018
@lock lock bot locked and limited conversation to collaborators Jan 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants