update-packages

This project is in an early alpha stage. Please use with extreme caution as this can alter your local and remote Git repositories, install npm packages, etc. It is recommended to test with a smaller folder or single repository first.

The steps that are taken are as follows:

1. Look through command line options and any config file
2. Find and cycle through the (non-hidden and non-excluded) targeted Git
   repository(ies) with package.json files.
   1. Get the current branch name and save it for later restoration
   2. If upgrading:
      1. Detect original branch so as to be able to switch back
         to it afterward (including upon error)
      2. Switch to the targeted branchName (defaulting to master)
   3. Upon erring in any of the following non-recovering steps, switch
      back to the saved branch.
   4. Check for npm package updates, updating if so requested
   5. If not upgrading, stop these steps.
   6. Attempt to run a local npm install (for the updates)
   7. Attempt to run an npm security audit and fix any automatable
      vulnerabilities as possible
   8. Run an npm test against the repository package
   9. Add any unstaged files to Git staging
   10. Attempt local commit (without global credentials)
   11. Upon failing, retrieve global Git config info and use for global
       commit attempt
   12. Push to origin
   13. Get remote names
   14. Push to each relevant remote
   15. Save report for potential future querying and resumption
   16. After all items complete, give final report of tasks completed
       (at end), sorted by stage of final failure (if any)

Installation

Globally:

npm install -g update-packages

Or locally (for development):

npm install -D update-packages

Command line usage

To view as non-embedded HTML or SVG files (for copy-pasteable commands):

• cli.html
• cli.svg

To-dos

1. Configuration
   1. Allow optional npm version/semver (which can bump version as
      appropriate per versions updated, do tagging (including a commit
      template with %s as variable for version number)) and/or
      publishing via npm publish; don't publish if private in
      package.json is true; option to only version if last was
      another versioned commit; allow adding old and resulting version
      to commit message as well as devDep vs. dep.
2. Document scripts for querying JSON out of report file
   (e.g., to find when last queried); currently using jq (though
   see https://github.com/s3u/JSONPath/issues/105 for desired
   jsonpath-plus support)? reformat report JSON if not ideal for
   querying

Possible future to-dos

1. Add tests
   1. Test master config file (as well as CLI) for indication of:
   2. Test pushing to multiple and alternate remote names besides
      origin.
   3. Test chunking/timing tasks to avoid heap error.
   4. Ensure still getting token
   5. Ensure npm-check-updates is taking into account ncurc files!
   6. Which repositories to include or exclude (in subdirectories)
   7. Which remotes to push to if any (by default when available and as
      exceptions)
2. Add a confirm updates option
3. Configuration
   1. Option to only perform operations if branch isn't switched
   2. We could configure by repo the following: ncu, branch, commit
      message, audit fix, and npm script (by default when available and as
      exceptions), but this is less critical, especially for ncu as it
      accepts config file
   3. Option to only apply if author is matched (e.g., to oneself)
   4. Option to stop if can't fix all security issues
4. Work with commit hooks
5. Add optional automated license check, lint fixing, etc. (if
   npm test doesn't handle)?
   1. Allow npm script to run (in place of test)
6. Collect and report back deprecated warnings for outdated/renamed
   packages (not performed currently
   by npm-check-updates); one can get info on a package with npm view <package name> deprecated --json (to get JSON string (e.g., opn-cli) or get nothing
   if not deprecated) but doesn't seem to show with npm ls or extended
   npm la.
7. We might ideally allow subscribing to an RSS feed of security notices
   so as to regularly poll for security updates and upon encountering one
   which was in a cached map of dependencies, would attempt to commit an
   update to that repo.
8. Could tap into https://github.com/npm/registry/blob/master/docs/follower.md
   (after caching info on all package-lock.json files) for auto-updating when
   changes to our repositories occur.