Update dependencies with peerDependencies at the end #48
Labels
Comments
|
In my case it was an issue with an eslint-config and eslint itself. |
Merged
jhnns
added a commit
that referenced
this issue
May 8, 2017
### Changes - A batch update is attempted for all **non-breaking** updates according to semver - All **breaking** updates are still performed in a sequential manner - If the batch update fails, the failed update tasks are performed sequentially to find out, which module was breaking - During a rollback, the next module update is installed in parallel - The `package.json` is now written in the end after the whole operation - The updtr tries to preserve the semver range style. If the style can not be preserved, it falls back to caret ranges. - This behavior can be changed by specifying a `--save` option - By specifying the `update-to=non-breaking` option, you can now choose to install non-breaking updates. It replaces the old `--wanted` flag - Re-design of the default reporter (it's now called `dense`) - Missing dependencies are now installed automatically before running `npm outdated` ### Fixes - Fixes #14 #47 #46 #13 #51 #58 - Provides a workaround for #48 by sorting all dependencies BREAKING CHANGE: New and changed CLI options ``` --use, -u Specify the package manager to use [choices: "npm", "yarn"] [default: "npm"] --exclude, --ex Space separated list of module names that should not be updated [array] --update-to, --to Specify which updates you want to install [choices: "latest", "non-breaking", "wanted"] [default: "latest"] --save, -s Specify how updated versions should be saved to the package.json [choices: "smart", "caret", "exact"] [default: "smart"] --reporter, -r Choose a reporter for the console output [choices: "dense", "none"] [default: "dense"] --test, -t Specify a custom test command. Surround with quotes. --test-stdout, --out Show test stdout if the update fails [boolean] --registry, --reg Specify a custom registry to use --version Show version number [boolean] --help Show help [boolean] ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If a dependency has a peerDependency on another dependency, we should update the peer first. Otherwise we may get a false positive because the peerDependencies just don't match anymore (although the code may work fine).
The text was updated successfully, but these errors were encountered: