Repository navigation
README uses npm commands, but the tool suggests to use yarn #1497
Description
This is the first time I've used create-react-app, which was pretty smooth and gave me the following message on the cli:
Success! Created react-prod-list at /Development/react-prod-list/
Inside that directory, you can run several commands:
yarnpkg start
Starts the development server.
yarnpkg run build
Bundles the app into static files for production.
yarnpkg test
Starts the test runner.
yarnpkg run eject
Removes this tool and copies build dependencies, configuration files
and scripts into the app directory. If you do this, you can’t go back!
We suggest that you begin by typing:
cd react-prod-list
yarnpkg start
Happy hacking!
However, when you browse the README.md file, all references are for npm, such as npm start, npm test, etc.
Activity
ro-savage commentedon Feb 8, 2017
I believe this is because you have yarn installed globally.
If you do not have yarn installed it would tell you to use
npm startetc.benjaminapetersen commentedon Feb 8, 2017
Yup. I added
yarnper suggestion from react docs site (I've historically usednpm, prob like most). Its a bit unsettling when you first install & then get conflicting information, I'm guessing theREADME.mdfile just needs a block for bothnpm&yarnto ensure new users that its not stale content.gaearon commentedon Feb 8, 2017
There is no difference between how those commands work. The intention was that Yarn users probably know what they're doing (Yarn still being a very new project), and should be familiar with npm anyway (since every library out there has instructions for npm and you can't avoid learning it). Maybe that was a wrong assumption?
[-]README.md file needs some updates![/-][+]README uses npm commands, but the tool suggests to use yarn[/+]gaearon commentedon Feb 8, 2017
By the way it's a bit unfortunate we're suggesting to run
yarnpkg startand similar whenyarn startwould work for most users. I know why we did that (to avoid conflicts with Yarn Java package) but can we somehow be smarter aboutyarndetection? cc @fsonfson commentedon Feb 8, 2017
I think by default we should show
yarncommands in the instructions and notyarnpkg. That was my intent when making the change to internally useyarnpkganyway, but looks like the instructions also got affected by the change.This is less than ideal for the minority of users who have both Yarn and that YARN Java package installed. We could assume that they'll find out how to use the
yarnpkgalias on their own (since that's what they need to do to use yarn in the first place) or else we'd need to add more complicated Yarn detection.Timer commentedon Feb 8, 2017
We could compare
command -v yarnandcommand -v yarnpkgand check if they're equal.fson commentedon Feb 8, 2017
@Timer That's an interesting idea! They output will be different however, on my system they return
/usr/local/bin/yarnand/usr/local/bin/yarnpkg, respectively. And our solution also needs to work on Windows.That gave me an idea though: maybe we could compare the output of
yarn --versionandyarnpkg --versionto give us a good enough heuristic that they're the same. The downside of any detection like this is that we would have to invoke the Yarn command twice in each script that shows the instructions (init,build,start), slowing down the execution (at the moment we only check ifyarn.lockexists). This would affect everyone, but only benefit those who need to use Yarn with theyarnpkgalias.Timer commentedon Feb 8, 2017
I think calling
yarnis cheap, I'm not sure about spinning up a process tho -- if it was a unix only solution we could do something like:We could have different checks for each OS?
Timer commentedon Feb 8, 2017
Actually, I'd even argue we stop suggesting
yarnfor windows users because it's insanely slow vsnpm.gaearon commentedon Feb 8, 2017
Is it still slow with the hoisting workaround? I think a lot of slowness is due to duplicate dependencies and the linking phase.
Timer commentedon Feb 8, 2017
I haven't tried it super recently but the linking stage just takes 200+ seconds, even longer when coupled with anti-virus.
gaearon commentedon Feb 8, 2017
I'm fairly sure this is at least partially alleviated by #1441.
viankakrisna commentedon Feb 22, 2017
Why not just use npm for the list of commands, and detect if the user installed yarn they can use that instead of npm? Something like
gaearon commentedon Feb 24, 2017
We already changed this in README so I think it's good to close.