Yarn: Split up add/update and remove upgrade

[caabernathy]

I'm using yarn v0.13.0

My assumption is that running yarn upgrade <package> updates a single package even if there are other.

Steps to reproduce

1/ Created the following package.json:

{
  "dependencies": {
    "lodash": "4.15.0",
    "gulp-helper": "1.0.3",
    "underscore": "1.6.0",
    "ansi-regex": "1.0.0",
    "is-fullwidth-code-point": "1.0.0"
  }
}

2/ Installed the packages: yarn install

3/ Checked the installed versions using npm ls:

├── [email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├── [email protected]
└── [email protected]

4/ Modified package.json to allow updates

{
  "dependencies": {
    "lodash": "^4.15.0",
    "gulp-helper": "^1.0.3",
    "underscore": "^1.6.0",
    "ansi-regex": "^1.0.0",
    "is-fullwidth-code-point": "^1.0.0"
  }
}

5/ Update one package: yarn upgrade underscore

6/ Check versions using npm ls:

├── [email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├── [email protected]
└── [email protected]

The expectation was that only underscore would be updated. All the others were as well.

[bestander]

I do yarn add without args when want to reflect all changes from
package.json into lock/node_modules

On 27 September 2016 at 22:59, Christine Abernathy <[email protected]

wrote:

I'm using yarn v0.13.0

My assumption is that running yarn upgrade updates a single
package even if there are other.

_Steps to reproduce_

1/ Created the following package.json:

{
"dependencies": {
"lodash": "4.15.0",
"gulp-helper": "1.0.3",
"underscore": "1.6.0",
"ansi-regex": "1.0.0",
"is-fullwidth-code-point": "1.0.0"
}
}

2/ Installed the packages: yarn install

3/ Checked the installed versions using npm ls:

├── [email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├── [email protected]
└── [email protected]

4/ Modified package.json to allow updates

{
"dependencies": {
"lodash": "^4.15.0",
"gulp-helper": "^1.0.3",
"underscore": "^1.6.0",
"ansi-regex": "^1.0.0",
"is-fullwidth-code-point": "^1.0.0"
}
}

5/ Update one package: yarn upgrade underscore

6/ Check versions using npm ls:

├── [email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├── [email protected]
└── [email protected]

The expectation was that only underscore would be updated. All the others
were as well.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/458, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACBdWJeO2yoo24fKVVKWFD7sTWkvncmcks5quZHVgaJpZM4KIM-t
.

[lacker]

What is yarn add without args supposed to do? We just wrote the docs for yarn add and I didn't know it was usable without args :P

[bestander]

It is reading package.json all modules from package.json and gets yarn.lock
and node_modules in sync with it

On 27 September 2016 at 23:06, Kevin Lacker [email protected]
wrote:

What is yarn add without args supposed to do? We just wrote the docs for yarn
add and I didn't know it was usable without args :P

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/458#issuecomment-250013400, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACBdWCuPFAdWxQWDo68_bX7SU8e2eDlIks5quZNbgaJpZM4KIM-t
.

[caabernathy]

Since this issues is related to documenting yarn upgrade the real question is whether the behavior described is intended. I was comparing it with the npm update command.

[lacker]

@bestander What is the difference between that and yarn install ?

[jamiebuilds]

I think because we're taking the time to split up add from install this is the ideal set of lifecycle commands:

$ yarn init
$ yarn add [depedency...]
$ yarn install
$ yarn update [dependency...]
$ yarn update # all?
$ yarn remove [dependency...]

Things outside of that set should be disallowed:

$ yarn install [dependency] # no, use `yard add [dependency]`
$ yarn add                  # no, use `yarn install`

[lacker]

So yarn add is only used for new packages, and yarn update is only used for pre-existing packages? That makes sense to me.

What happens if you already have e.g. version 3.4.5 of package foo but you want to fix it at version 4.5.6 - do you do yarn add [email protected] and/or yarn update [email protected]?

[bestander]

To me 'yarn update' is redundant.
I always use 'yarn add package@~version' to update a dep.
I wonder if anyone feels the same.
Afaik update was added to mimick npm

On Wednesday, 28 September 2016, Kevin Lacker [email protected]
wrote:

So yarn add is only used for new packages, and yarn update is only used
for pre-existing packages? That makes sense to me.

What happens if you already have e.g. version 3.4.5 of package foo but
you want to fix it at version 4.5.6 - do you do yarn add [email protected] and/or yarn
update [email protected]?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yarnpkg/yarn/issues/458#issuecomment-250029658, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACBdWOHzatqQ1XPK3cC_keZGbN3iN7Vpks5quafXgaJpZM4KIM-t
.

[jamiebuilds]

yarn update is no more redundant than having a separate add command from an install command when they do the same work internally. The reason for the yarn add api is to have an easier to understand API, it only makes sense to have commands that match each part of the workflow.

In addition to that, having separate commands means that we can target improvements to specific parts of the Yarn workflow.

[lacker]

If yarn add both adds packages and updates them, we might as well just have it all be under a single yarn install command so that it works just like npm and is familiar to npm developers. It makes sense to build an ideal API, it would also make sense to mimic npm, but it does not really make sense for half of the functionality in an area to mimic npm and half of it to be rewritten with a different style.

[jamiebuilds]

@lacker It used to be a single command, it was purposefully split apart, please see previous discussions.

[sebmck]

We should remove upgrade and just recommend use of add.

[jamiebuilds]

I disagree, recommending use of add is really confusing and there are downsides to reusing the same command as I mentioned before.

It's much easier to explain:

• yarn add [package]: add a new package
• yarn update [package]: update an existing package
• yarn remove [package]: remove an existing package
• yarn install: Install all of the packages

This is a cheap thing to do and much easier to remember, doing something halfway in between this and using yarn [un]install for everything is needlessly confusing.

[wycats]

@thejameskyle I agree.

One major problem with using add for update is that if I already have meow 1.3 installed and I write yarn add meow, what I want is ambiguous. It's reasonable to believe that it does nothing (since it's already installed) and reasonable to believe it performs an update.

yarn update meow is unambiguous: it means "do an update plz". I think this makes it superior. It also has precedent in other package managers.

Aside: fwiw, both bundler and cargo allow yarn update with no args to mean "update everything", which more or less resets the lockfile and re-resolves. I find it useful (and better than rm yarn.lock && yarn install)

[bestander]

In that case we would need to make update smarter: it should update dev, peer and normal dependencies.
And also fail when a person tries to add a dependency that already exists.
Another use case: we have a dev dependency and now I want to add it to peer dependency, I suppose add should not fail when a dependency is added to another list (react-native depends on react as dev and peer dependency)

On the other thought, do we need all these semantics around updating package.json?

[jamiebuilds]

Could someone make a PR with these changes before release? I would do it myself but I'm still trying to get the documentation in order.

[cpojer]

Yes I'm happy to do it but I'm waiting for @kittens' big diff to get merged.

[sebmck]

Already did this as a part of #439 with f0f94af8538cb87795d1cd9c72a293d22c00c6c4.