Yarn: Update yarn install help content to point to yarn add commands next to deprecation warnings

[axefrog]

    -g, --global                DEPRECATED
    -S, --save                  DEPRECATED - save package to your `dependencies`
    -D, --save-dev              DEPRECATED - save package to your `devDependencies`
    -P, --save-peer             DEPRECATED - save package to your `peerDependencies`
    -O, --save-optional         DEPRECATED - save package to your `optionalDependencies`
    -E, --save-exact            DEPRECATED
    -T, --save-tilde            DEPRECATED

Yet on the npm migration page, it lists all of those options without any mention of deprecation. What's the story here? Are we no longer supposed to distinguish between different dependency contexts? I also noticed that dependencies are not saved by default to package.json, so I'm really not sure what is intended, other than maybe we're not supposed to reference dependencies in package.json anymore?

[Daniel15]

With Yarn, you use yarn add rather than yarn install --save. Yarn intentionally splits adding a new dependency (yarn add) from installing dependencies already referenced in package.json (yarn install).

[jamiebuilds]

We should improve the help content to say the same things as running yarn add X --save*

[axefrog]

@Daniel15 I discovered the correct options via yarn add -h, but this would have been a lot easier if (a) they were listed as part of the main CLI help, as that's where most people look for this stuff, and (b) the documentation for those migrating from NPM displayed the correct information. I suspect, being barely a week old, that this stuff will be sorted out sooner or later. :D

[bestander]

Should be resolved now

[gardner]

Where is the appropriate place to provide feedback on changes like this?

[bestander]

@gardner, for discussion probably an issue here.
For a change proposal that may involve breaks an RFC https://github.com/yarnpkg/rfcs

[gardner]

I just wanted to say how impressed I am with yarn's performance and adoption by the community shows that everybody appreciates the changes. Thanks for making it.

Building new habits takes work. Working in a dynamic and sometimes fragmented ecosystem of forks and releases with breaking changes can be really tough just to keep up with the latest. I find a lot of value in tools that don't require me to change my habits.

If there exists a mapping between yarn and npm functionality then why would we deprecate that functionality, break backwards compatibility, and require the user to type two commands instead of one? I can work around this issue for myself with aliases or scripts. I am curious as I see hundreds of thousands of developers potentially receiving this deprecated error in the future and I am having trouble seeing the value in the change.

@Daniel15 mentions that yarn "intentionally splits" this functionality. Looking in the history it appears that @kittens touched that code late last year. Is there a ideological, design, or maintenance reason to ask so many people to change their behavior?

Thanks,
Gardner

[BYK]

@gardner would this work you: https://yarnpkg.com/en/docs/migrating-from-npm

[gardner]

Thanks for the link @BYK. I understand that there is a mapping between some npm and yarn functionality. That is my point. The question is: Why does yarn throw an error instead of support npm style arguments? The error message tells me what the mapping is:

error `install` has been replaced with `add` to add new dependencies.
Run "yarn add module" instead.

Why would we force users to use a different syntax when the given arguments are understood?

[BYK]

@gardner because we think yarn can be used to make certain things better and this is one of them. Since yarn is a separate tool, it is not burdened with the backwards-compatibility requirements of npm.

Which part of that messaging makes you upset and how can we improve it? Is the tone too aggressive or didactic? Would you appreciate a short link to the docs I've shared above in the command output?

[gardner]

Thanks @BYK. The error message is fine. It is more just an inconvenience for me to have hit and error message and then change the command that I type even though the software explains that it knows what I want to do and then requires that I do it the new way. It forces me to accommodate it instead of it accommodating me.

I understand if there are a different opinions on the way syntax should be and I fully support this project to implement it in whichever way y'all want. I just wanted to provide my feedback on it. Thanks again for taking the time to engage.

[BYK]

It forces me to accommodate it instead of it accommodating me.

It is not great to make people feel that way. Honest question: if it said Please, run "yarn add module" instead would it change how you look at it? :)

[gardner]

It would be better if it took the quoted command that it is printing in the error message and just executed it so that I don't have to type it. ;)

How would y'all feel about a pull request with a disabled-by-default config option to support legacy npm-style command line arguments?

[pvinis]

@gardner this might be of interest to you. github.com/nvbn/thefuck