Hi, thanks for this tool.
I had problems using updtr on node 6 (node 4 is fine)

Found that isExcluded() in filter.js returns null on node 6.
So i made a little fix for myself in isExcluded function:

changed line 23 to:
return !!info.name.match(new RegExp("^(" + excludedModules.join("|") + ")$"));

Just updated to 1.0.0 and got this error when running (Node v7.5.0):

❯ updtr
Looking for outdated modules... ⠲ undefined:2
{"type":"finished","data":978}
^

SyntaxError: Unexpected token { in JSON at position 922
    at JSON.parse (<anonymous>)
    at /usr/local/lib/node_modules/updtr/lib/run.js:122:25
    at ChildProcess.exithandler (child_process.js:202:7)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:192:7)
    at maybeClose (internal/child_process.js:890:16)
    at Socket.<anonymous> (internal/child_process.js:334:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:189:7)
    at Pipe._handle.close [as _onclose] (net.js:501:12)

If I have dependencies of which the installed version is not up to date but the latest version is still included in the range which I have stated in my package.json, I would expect updtr not to write to my package.json but just update the installed version after a successful test instead. It's not necessary to write to the package.json in this case. That only creates unnecessary commits. We could also make this a flag for the CLI which defaults to the behavior described above. What do you guys think?

Any interest in adding support to use yarn over npm when it's installed?

When the user presses ctrl/cmd + c (thus sending SIGINT to the process), updtr should print a message to the console like I'll stop updating your modules, just let me finish the current update. Currently, when the user sends SIGINT, updtr just stops and leaves the project in an invalid state.

while i wouldn't want a stable version upgraded to a prerelease version or a prerelease version downgraded to a stable version, it would be valuable to have a prerelease version upgraded to a newer prerelease version.

We have a quite a lot of specs executed upon "npm test" and would like to see the test output in order to know why a dependency could not be updated. Is it possible?

I have this one project that uses the urlsafe-base64 package. In order to use Yarn, I explicitly need to pass --ignore-engines to yarn.

Can we pass any additional switches after -- to the underlying package manager that's going to apply the updates? The command would be something like updtr --save-exact -- --ignore-engines.

We have a big slow test suite, and a lot of dependencies. I fear running updtr will take all night. But perhaps there is a faster way, using a binary search:

1. updtr updates all the packages to the latest versions.
2. It runs the tests. If they succeeded, then we are finished.
3. Otherwise one of the tests failed. Reverts half of the upgrades it just made, and test again.
4. If the tests now succeed, updtr knows which half of the upgrades the problem upgrade(s) live in. Focus on that half.
   Otherwise, if the tests failed, updtr needs to keep testing both halves to track down the problem upgrade(s).
5. Define this algorithm better, then try to explain it again. ;-)

I hope you get the idea. (If you have 32 dependencies, and one of them is breaking, a binary search could find it by running the test suite 5 times instead of 32 times.)

(Optional: Once a package has been identified as breaking the tests, updtr could even do a binary search on the versions to determine the exact version which caused the breakage.)

After running updtr, some of the packages I had specified in my package.json have changed in their specifity. updtr has changed some of them to be more specific and some of them to be less specific as before. Here's the output of git diff package.json after running updtr:

     "extend": "^3.0.0",
-    "gulp-angular-templatecache": "^1.8.0",
+    "gulp-angular-templatecache": "^2.0.0",
     "gulp-autoprefixer": "^3.1.0",
     "gulp-bootlint": "^0.8.0",
-    "gulp-changed": "1.3.0",
+    "gulp-changed": "^1.3.2",
     "gulp-clean-css": "^2.0.4",
     "gulp-csso": "^2.0.0",
-    "gulp-header": "1.8.2",
-    "gulp-htmllint": "^0.0.8",
+    "gulp-header": "^1.8.2",
+    "gulp-htmllint": "0.0.8",
     "gulp-htmlmin": "^2.0.0",
     "gulp-typescript": "^2.7.5",
-    "gulp-uglify": "^1.1.0",
+    "gulp-uglify": "^2.0.0",
     "gulp-util": "^3.0.4",
     "inquirer": "^1.0.3",
-    "karma": "^0.13.19",
+    "karma": "^1.2.0",
     "karma-chai": "^0.1.0",
-    "karma-coverage": "1.1.0",
+    "karma-coverage": "^1.1.1",
     "karma-mocha": "^1.0.1",
-    "karma-mocha-reporter": "2.0.4",
+    "karma-mocha-reporter": "^2.1.0",
     "karma-ng-html2js-preprocessor": "^1.0.0"

For some of them it added a ^ and for some of them it removed it. I think we should have a flag that allows to either keep the existing specifity or replace it with the recommended one instead. By default, I would expect it to keep the existing specifity.

This is what it looks like in package.json:

"nock": "^7.2.2",

As far as npm is concerned 7.2.2 is the latest version: https://www.npmjs.com/package/nock (as of 2016-03-11)

I just wanted to do a non-breaking update on all dependencies in an example project without tests and I executed updtr --to non-breaking -t "exit 0". After installing all updates, I received:

 ERROR  Cannot read property 'version' of undefined
    at /Users/jhnns/dev/peerigon/updtr/dist/index.js:1021:85
    at Array.map (<anonymous>)
    at _callee$ (/Users/jhnns/dev/peerigon/updtr/dist/index.js:1015:25)
    at tryCatch (/Users/jhnns/dev/peerigon/updtr/node_modules/regenerator-runtime/runtime.js:65:40)
    at Generator.invoke [as _invoke] (/Users/jhnns/dev/peerigon/updtr/node_modules/regenerator-runtime/runtime.js:303:22)
    at Generator.prototype.(anonymous function) [as next] (/Users/jhnns/dev/peerigon/updtr/node_modules/regenerator-runtime/runtime.js:117:21)
    at step (/Users/jhnns/dev/peerigon/updtr/node_modules/babel-runtime/helpers/asyncToGenerator.js:17:30)
    at /Users/jhnns/dev/peerigon/updtr/node_modules/babel-runtime/helpers/asyncToGenerator.js:28:13
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

universal master ✗ 71c4a26 195d △ ⍉ ➜ npm -v
5.7.1
universal master ✗ 71c4a26 196d △ ➜ node -v
v9.2.0
universal master ✗ 71c4a26 196d △ ➜ 

When my repository is using a version higher than @latest, it downgrades to whatever is @latest. But if the currently installed version is higher than @latest, it shouldn't do anything

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

Hello,

I was trying to use updatr on a project that use outdated dependencies, but I had this error :

λ updatr --help
Updating node and npm
Updating brew
Updating rvm
updatr complete.
C:\Users\cperois\AppData\Roaming\npm\node_modules\updatr\bin\updatr:23
  if (err) throw err;
           ^

Error: Command failed: C:\WINDOWS\system32\cmd.exe /s /c "rvm get stable"
'rvm' n'est pas reconnu en tant que commande interne
ou externe, un programme ex�cutable ou un fichier de commandes.

    at ChildProcess.exithandler (child_process.js:213:12)
    at emitTwo (events.js:87:13)
    at ChildProcess.emit (events.js:172:7)
    at maybeClose (internal/child_process.js:821:16)
    at Socket.<anonymous> (internal/child_process.js:319:11)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)
    at Pipe._onclose (net.js:469:12)

The error is in french, but it mean " 'rvm' is not recognized as an internal or external command, an executable or a commands file".

Am I doing something wrong ?

Thanks.

The following line of code presents line 92 of run.js, version 0.1.4:

info.saveCmd = info.type === "devDependencies" ? "--save-dev" : "--save";

If I follow the source correctly, this is used to make the difference between your dependencies being saved in devDependencies or dependencies.

But when I use the plugin all the dependencies are always placed in "dependencies", even if they are originally contained in "devDependencies".

In the test file there is also no mention of devDependencies 😄.

Anyone else facing the same issue that can confirm this? I'm at the moment unable to pull the code and add tests to check thoroughly.

i have a few of projects that need to prevent updates for a couple of pinned dependencies. i'm able to do this with updtr if i remember to provide the --exclude flag. the problem, though, is remembering to do that.

it would be great if i could capture config that i need to use repeatedly per project in a way that could be versioned with the project.

i've seen that a number of projects are now using cosmic-config to simplify getting config info into cli-based apps and make it flexible for consumers to decisde where they define their config. personally, i've given up on keeping the root of my projects clear of config files, so i'd be happy to add a .updtrrc to my collection of rc files that already litters all of my projects.

would something along these lines be possible to save us from forgetting to provide config directly on the cli?

eg: updtr --registry https://registry.npm.taobao.org

Hi,
I have an angular 6 project running and everything works like charm but when I'm trying to add a new component using angular-cli tool (version 6) I get the following error.

ng g component x (where x is the name of the new component)
error message: "unexpected token ] in json at position 848"

any suggestions?

Hi at first, thx for you nice tool.

I get some strange behaviour with my packages.
I have to run updtr twice to update all dependencies.

My local installed Packages:

  "devDependencies": {
    "grunt": "^0.4",
    "grunt-contrib-watch": "^0.6",
    "grunt-contrib-compass": "^1",
    "grunt-contrib-imagemin": "^0.8",
    "grunt-contrib-uglify": "^0.9",
    "grunt-jsdoc": "^0.6"
  }

[1] i run updtr,
-- the update for grunt package fails
-- all the other packages updates to its latest version
[2] i run updtragain,
-- now grunt package updates to latest version

Question:
is this behaviour correct?

I am not sure this is a bug or a strategy, It's very dangerous and against my will

-    "koa": "^2.0.0",
+    "koa": "^1.2.0",

-    "koa-static": "^3.0.0",
+    "koa-static": "^2.0.0",

-    "webpack": "^2.1.0-beta.5"
+    "webpack": "^1.13.0"

There are certain projects where I prefer to use an older version of certain dependencies (Babel 5 related). Would it make sense to implement some kind of a mechanism to allow skipping these? A lazy way would be to do something like .updtrignore:

babel-eslint
babel-loader

It simply wouldn't touch these files when running. Of course the con is that you end up having one more dotfile at your project. A decent alternative would be to push this information to package.json and parse it from there.

I'm currently using the alpha version of istanbul to collect coverage information with es6 code. However, when I run updtr, it always replaces it with the latest stable version. I understand not wanting to "upgrade" those projects that have specified a stable version to the pre-release, but since I have specified the alpha, I'd prefer not to be downgraded either.

I'm not sure if dist-tags or semver is the safer way to identify a pre-release, so I'll leave that decision to you, but some interesting things about the specific istanbul case are:

• they do not tag the alpha version with an alpha tag, but rather a next tag
• the alpha that is tagged with next is not the latest alpha version

I'd be happy to suggest modifications to how they manage their releases, but wanted to start here so that if I do need to suggest a change to their project that it would align with this projects goals as well.

Hey there! Love your module, but have a couple of concerns. One of them is described in this issue, so let me jump to the second one.

Is there a way to save formatting in package.json? We divide dependencies into the blocks separated by empty line, for example we have unit-testing dependencies, code linting dependencies, webpack-related, babel-related, etc. updtr though squashes them together and sorts alphabetically which breaks the structure. Any way to put it under the special flag like --keep-structure or something? Thanks.

It would be nice to get a preview of what updtr is planning before letting it give it a shot, for my workflow; I can use npm outdated to get what I expect to be the same information, but I have not inspected the code of updtr to verify that this will necessarily always be correct.

I am not thinking "run the tests with the update, but do not commit it", but rather, "show what will be tried." The attempt may, of course, fail, and lead to the normal handling of test failures after update, which may vary from the plan.

I am thinking of a display specifically of something like:

# package.json contains "is-binary-path": "^1.0.0"
] updtr --what-you-planning-machine
[email protected] ⃗ [email protected]
] updtr --what-you-planning-machine --to wanted
[email protected] ⃗ [email protected]

You, uh, might want to find someone more competent at naming things than me to work out what the flag should be called, though. :)

Currently, we mock our exec calls. This makes our tests very fast, but doesn't give us any insights if updtr would actually work under real-world conditions. We should add 2-3 integration tests and run them on Travis against different versions of npm and yarn.

The default reporter works great from the terminal but if you are pushing it to a file or viewing it via a CI console it ends up spamming you with a lot of lines.

e.g. moment testing... ↘ 12/16 ● moment testing... ↓ 12/16 ● moment testing... ↙ 12/16 ● moment testing... ← 12/16 ● moment testing... ↖ 12/16 ● moment testing... ↑ 12/16 ● moment testing... ↗ 12/16 ● moment testing... → 12/16 ● moment testing... ↘ 12/16 ● moment testing... ↓ 12/16 ● moment testing... ↙ 12/16 ● moment testing... ← 12/16.

It would be really helpful if there was a reporter that still told you something but just printed at each point rather than continuously. So you ended up with something like

Looking for outdated modules
updating
testing
rolling back
success/fail
etc...

Given a config like:

  "devDependencies": {
    "@types/jest": "^26.0.5",
    "@types/node": "^14.0.23",
    "bats": "https://github.com/bats-core/bats-core/archive/v1.2.1.tar.gz",
    "bats-assert": "git+https://github.com/bats-core/bats-assert.git",
    "bats-file": "git+https://github.com/bats-core/bats-file.git",
    "bats-support": "git+https://github.com/bats-core/bats-support.git",
    "jest": "^26.1.0",
    "prettier": "^2.0.5",
    "tiny-invariant": "^1.1.0",
    "ts-jest": "^26.1.3",
    "typescript": "^4.0.0-beta"
  }

Updtr fails with:

$ npx updtr
npx: installed 75 in 2.897s
Looking for outdated modules...
> npm outdated --json --depth=0 
⠹

 ERROR  Invalid Version: remote
    at new SemVer (/home/ivan/.npm/_npx/11875/lib/node_modules/updtr/node_modules/semver/semver.js:323:11)
    at compare (/home/ivan/.npm/_npx/11875/lib/node_modules/updtr/node_modules/semver/semver.js:614:10)
    at Function.lte (/home/ivan/.npm/_npx/11875/lib/node_modules/updtr/node_modules/semver/semver.js:668:10)
    at Object.test (/home/ivan/.npm/_npx/11875/lib/node_modules/updtr/dist/index.js:841:10)
    at /home/ivan/.npm/_npx/11875/lib/node_modules/updtr/dist/index.js:866:28
    at Array.findIndex (<anonymous>)
    at filterUpdateTask (/home/ivan/.npm/_npx/11875/lib/node_modules/updtr/dist/index.js:865:35)
    at /home/ivan/.npm/_npx/11875/lib/node_modules/updtr/dist/index.js:921:5
    at Array.map (<anonymous>)
    at /home/ivan/.npm/_npx/11875/lib/node_modules/updtr/dist/index.js:920:42

Here are some examples on how I would expect it to work out of the box:

~3     --> ~4
~2.1   --> ~4.2
~2.0.0 --> ~4.0.2
 1.2.0 -->  2.3.7 
 1.x.x -->  3.x.x
^2.1.9 --> ^3.0.1
 0.0.0 -->  3.0.2

The current state of this repo is, that the coverage of ~92% fails the 94% threshold, so all builds based on master fail.

Why is it 94%?
Could we make it 90%?
What more can we test?
Could we make it 100%? 😱

On:

• Windows 10
• Node 6.8.1
• Npm 4.0.1

Trace:

Looking for outdated modules... ⠲ C:\Users\ThomasSileghem\AppData\Roaming\nvm\v6.8.1\node_modules\updtr\bin\updtr:38
        throw err;
        ^

Error: Command failed: npm outdated --json --long --depth=0

    at ChildProcess.exithandler (child_process.js:206:12)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Socket.<anonymous> (internal/child_process.js:334:11)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:188:7)
    at Pipe._handle.close [as _onclose] (net.js:498:12)

Awesome tool, I just have a small, very low priority issue with it: I use tabs in my package.json – I know, right? npm totally respects my decision, updtr does not, here's a reproducible testcase:

mkdir updtr-test
cd updtr-test
npm init --yes

gives us this package.json:

{
  "name": "updtr-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Now remove the test (so updtr doesn't fail later) and entab:

{
	"name": "updtr-test",
	"version": "1.0.0",
	"description": "",
	"main": "index.js",
	"scripts": {},
	"keywords": [],
	"author": "",
	"license": "ISC"
}

then npm i [email protected], which is an old version. package.json looks like:

{
	"name": "updtr-test",
	"version": "1.0.0",
	"description": "",
	"main": "index.js",
	"scripts": {},
	"keywords": [],
	"author": "",
	"license": "ISC",
	"dependencies": {
		"del": "^2.2.2"
	}
}

So tabs all the way. Nice. Now run updtr, lo and behold:

{
  "name": "updtr-test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {},
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "del": "^3.0.0"
  }
}

... we're back to 2 spaces, or as I call it: no indentation at all.

Nothing prettier doesn't solve for me, just a small issue. Great tool tho!

Not sure why this fails, but just reporting it.

I got around it with updtr --exclude react

When I converted my project over to Yarn Workspaces I noticed that updtr no longer works.

When I try and update on the sub-packages it adds ever single package available to all packages to that sub-package. If needed let me know and I can create an example repo.

Problem

I was testing updtr on a project running on node 0.12.x. All tests were passing so I've tried to update from eslintify version 2.x to eslintify version 3.x.

Problem is, eslintify v3 is dependent of eslint which is compatible node >= 4 engines due usage of const and some other modern syntax but eslintify was part of a browserify task that wasn't involved with tests, only a watch while editing before building for prod.

TL;DR

Running against tests doesn't necessarily mean all libraries/modules in the package list are used.
I understand updtr cannot do magic but at least it could compare current module and all its dependencies against current node engine version and avoid, where specified in the package.json engines fields, any sort of trouble (or warn about possible engine version conflict and ask confirmation for the upgrade)

Thanks for considering this.

The way updtr --help explains it, does not work for me:

--exclude, --ex Space separated list of module names that should not be updated [array]

The only way I get it to work properly is by doing it this way:
updtr --ex less --ex express

I've noticed that updtr will update a dependency to its beta release if one is available. (I assume the same holds true for release candidates, although I haven't tested that specifically.) I feel this is usually not the expected behavior. Is it possible to make this behavior available under a flag and only use stable releases by default?

For example, if I created a command "npm run print-webpack-bundle-size", I would like a way to tell updtr to run that command in between each package upgrade so I can keep track of which upgrades are causing my bundle.js to become bloated.

When updtr tries updating a module that's not installed, it failes with this command:

Error: Command failed: /bin/sh -c npm i babel-tape-runner@undefined --save-dev

running npm outdated I can see that the dependency is currently missing:

running npm i before updtr obviously fixes the issue, so it's not really a problem - just wanted to let you know.

updtr --version : 3.1.0
yarn version 1.13.0-20181004.1525

❯ .\node_modules\.bin\updtr
Running updtr with custom configuration:

o use: yarn

Looking for outdated modules...
> yarn outdated --json --flat
  .

 ERROR  Error when trying to parse stdout from command 'yarn outdated --json --flat': Could not find object with type === table
    at yarnParser (E:\repos\virtuoso\node_modules\updtr\dist\index.js:1665:11)
    at parse$1.yarn.outdated.stdout (E:\repos\virtuoso\node_modules\updtr\dist\index.js:1710:22)
    at Object.outdated (E:\repos\virtuoso\node_modules\updtr\dist\index.js:1609:14)
    at getUpdateTasksFromStdout (E:\repos\virtuoso\node_modules\updtr\dist\index.js:879:3)
    at E:\repos\virtuoso\node_modules\updtr\dist\index.js:915:28
    at Generator.throw (<anonymous>)
    at asyncGeneratorStep (E:\repos\virtuoso\node_modules\@babel\runtime\helpers\asyncToGenerator.js:3:24)
    at _throw (E:\repos\virtuoso\node_modules\@babel\runtime\helpers\asyncToGenerator.js:29:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)

output of yarn outdated --json --flat:

{"type":"info","data":"Color legend : \n \"<red>\"    : Major Update backward-incompatible updates \n \"<yellow>\" : Minor Update backward-compatible features \n \"<green>\"  : Patch Update backward-compatible bug fixes"}
{"type":"table","data":{"head":["Package","Current","Wanted","Latest","Package Type","URL"],"body":[["@ember-decorators/babel-transforms","2.1.1","2.1.2","2.1.2","devDependencies","https://github.com/ember-decorators/babel-transforms#readme"],["@neighborly/ui","0.0.22","0.0.22","0.1.0","devDependencies","https://github.com/neighborly/neighborly-ui#readme"],["@types/ember","3.0.20","3.0.24","3.0.24","devDependencies","https://github.com/DefinitelyTyped/DefinitelyTyped.git"],["@types/ember__test-helpers","0.7.3","0.7.5","0.7.5","devDependencies","https://github.com/DefinitelyTyped/DefinitelyTyped.git"],["@types/ember-data","3.0.2","3.1.1","3.1.1","devDependencies","https://github.com/DefinitelyTyped/DefinitelyTyped.git"],["@types/ember-qunit","3.4.1","3.4.2","3.4.2","devDependencies","https://github.com/DefinitelyTyped/DefinitelyTyped.git"],["@types/ember-test-helpers","1.0.2","1.0.3","1.0.3","devDependencies","https://github.com/DefinitelyTyped/DefinitelyTyped.git"],["ember-cli-babel","6.17.2","6.17.2","7.1.2","devDependencies","https://github.com/babel/ember-cli-babel#readme"],["ember-cli-htmlbars","3.0.0","3.0.1","3.0.1","devDependencies","https://github.com/ember-cli/ember-cli-htmlbars"],["ember-cli-htmlbars-inline-precompile","1.0.3","1.0.4","1.0.4","devDependencies","https://github.com/ember-cli/ember-cli-htmlbars-inline-precompile#readme"],["ember-cli-typescript","1.4.3","1.4.4","1.4.4","devDependencies","https://github.com/typed-ember/ember-cli-typescript"],["ember-decorators","2.5.0","2.5.2","2.5.2","devDependencies","https://ember-decorators.github.io/ember-decorators"],["ember-power-select","2.0.8","2.0.9","2.0.9","devDependencies","http://www.ember-power-select.com"],["ember-source","3.4.3","3.4.5","3.4.5","devDependencies","https://emberjs.com/"],["eslint-plugin-prettier","2.7.0","2.7.0","3.0.0","devDependencies","https://github.com/prettier/eslint-plugin-prettier#readme"],["husky","1.0.1","1.1.1","1.1.1","devDependencies","https://github.com/typicode/husky#readme"],["sass","1.14.0","1.14.1","1.14.1","devDependencies","https://github.com/sass/dart-sass"],["typescript","3.0.3","3.1.1","3.1.1","devDependencies","http://typescriptlang.org/"],["typescript-eslint-parser","19.0.1","19.0.2","19.0.2","devDependencies","https://github.com/eslint/typescript-eslint-parser"]]}}

I'm on Windows 10 and running in powershell.

npm outdated won't report versions properly for linked modules, so you'll have to manually inspect them. use case: use updtr with pnpm

From the README I'm assuming this project doesn't work with Pnpm . Is this something you'd like to support? Wouldn't mind looking into this if so.

The first time I ran updtr I got this output:

Some modules are not installed. Please install with 'npm install' first.

It would be helpful if the error message included the names of affected modules.

Hey guys,

Great module!
However, I have a concern about the README.md. It may sound like a joke, but oh well.

The README.md states "Update outdated npm modules with zero pain™", but it's unclear what is (jokingly) trademarked, making it sound like "pain" is the focus of the so-called trademark. It might be interesting to rephrase it to avoid confusion.

Again, I'm not kidding! It's confusing and might degrade the image of the module.

Regards,