tbranyen / salita Goto Github PK

View Code? Open in Web Editor NEW

95.0 5.0 8.0 160 KB

Automatically upgrade all NPM dependencies.

License: MIT License

JavaScript 100.00%

salita's Introduction

Salita

Automatically upgrade all dependencies and devDependencies to their latest stable semver.

Install

npm install salita -g

Usage

# Change into directory with package.json.
cd my_project

# Upgrade all dependencies.
salita

Options

--no-color: prevents colorized output
--json: provides parseable JSON output (also disables colors)
--dry-run / -n: prevents changes to package.json
--update: reflects the changes in package.json
--ignore-stars: ignore updates to packages that are set to "*"
--ignore-pegged: ignore updates to packages that are pegged to a single version, rather than a range
--check: implies "dry-run"; and returns with an exit code matching the number of updated dependencies.
--only-changed: only show packages that have (or would have) changed

Example

You can see in the example below that dependencies are always resolved to their latest stable, instead of just the latest version tagged:

salita's People

Contributors

Stargazers

Watchers

Forkers

incompl cybernetics xotic750 shopglobal franciscoponcegomez kraravind167 brennaheaps

salita's Issues

`salita --no-color` does not appear to work

When I execute salita --no-color I still get output with colour, or am I doing something wrong?

Publish a new version to npm

I'd love to get a version published that includes #2 :-)

Does not pickup the greatest version

e.g.

npm info gaze

{ name: 'gaze',
  description: 'A globbing fs.watch wrapper built from the best parts of other fine watch libs.',
  'dist-tags': { latest: '0.5.2' },
  versions:
// ..
     '0.4.2',
     '0.4.3',
     '0.5.0',
     '0.5.1',
     '0.5.2',
     '0.6.0',
     '0.6.1',
     '0.6.2',
     '0.6.3',
     '0.6.4' ],
  maintainers: [ 'joshperry <[email protected]>', 'shama <[email protected]>' ],
  time:
   { modified: '2015-10-05T20:28:06.595Z',
     created: '2012-10-04T17:46:14.249Z',
// ..
     '0.6.1': '2014-04-14T05:31:53.674Z',
     '0.6.2': '2014-04-14T18:31:18.128Z',
     '0.6.3': '2014-04-15T03:03:33.464Z',
     '0.6.4': '2014-04-21T18:40:11.152Z',
     '0.5.2': '2015-10-05T20:28:06.595Z' },
// ..

Notice that the greatest version is 0.6.4 but the latest version is 0.5.2. salita wrongly picks up the latest, not the greatest version.

Dry-run doesn't work on 0.9.1

λ salita -v
0.9.1
λ salita -n
Options:
  --color          colorizes output  [boolean] [default: true]
  --no-color       prevents colorized output
  --json           provides parseable JSON output (implies --no-color)  [boolean]
  --dry-run, -n    prevents changes to package.json  [boolean] [default: false]
  --update, -u     applies changes to package.json  [boolean] [default: true]
  --ignore-stars   ignore updates to packages that are set to "*"  [boolean]
  --ignore-pegged  ignore updates to packages that are pegged to a single version, rather than a range  [boolean]
  --check          implies --dry-run and --no-update, and returns with an exit code matching the number of updated dependencies  [boolean]
  --help, -h       Show help  [boolean]
  --version, -v    Show version number  [boolean]

Error: --update and --dry-run are mutually exclusive

Info: NPM > 6.5.0

Should you update the dependencies, things break if you update NPM > 6.5.0. As you have no tests, if you have a package.json like this

{
  "name": "tests",
  "version": "1.0.0",
  "dependencies": {
    "json3": "^3.1.0"
  },
  "devDependencies": {
    "safe-to-string-x": "1.5.0"
  },
  "peerDependencies": {
    "jquery-ui": "*",
    "safe-to-string-x": "^1 || ^2"
  }
}

where safe-to-string-x is in devand peer, it fails with a semver error from npm/lib/view

Update pegged dependencies but keep them pegged

Dependencies in my package.json are pegged, eg "@types/node": "16.11.17". When we decide to run Salita and update the dependencies, the version is updated correctly but they stopped being pegged.

eg "@types/node": "16.11.17" -> "@types/node": "^17.0.5"

We then either have to do a manual search and replace or our Renovate Bot changes them to be pegged and creates a merge request. Either way, it's a bit of extra work that I would like to avoid.

Ideally I would like Salita to recognise that the dependency is pegged and when it updates it, it remains pegged,

eg "@types/node": "16.11.17" -> "@types/node": "17.0.5"

Alternatively there could be a command line option for it.

Specify which semver level to upgrade

Coworker mentioned how they'd like to upgrade just to the patch level. I realized that salita doesn't offer that level of granularity, but it could. Thoughts on being able to specify:

--major Update to the latest major
--minor Update to the latest minor
--patch Update to the latest patch

--check is broken

$ salita --version
0.9.2
$ salita --check
Options:
  --color          colorizes output  [boolean] [default: true]
  --no-color       prevents colorized output
  --json           provides parseable JSON output (implies --no-color)  [boolean]
  --dry-run, -n    prevents changes to package.json  [boolean] [default: false]
  --update, -u     applies changes to package.json  [boolean] [default: true]
  --ignore-stars   ignore updates to packages that are set to "*"  [boolean]
  --ignore-pegged  ignore updates to packages that are pegged to a single version, rather than a range  [boolean]
  --check          implies --dry-run and --no-update, and returns with an exit code matching the number of updated dependencies  [boolean]
  --help, -h       Show help  [boolean]
  --version, -v    Show version number  [boolean]

Error: --update and --check are mutually exclusive

show only Changed packages

This is a great package; can you add an option to show only Changed packages

no such file or directory

Getting this on a fresh node install.

curiosity:react-youtube-player gajus$ nvm install 4.2.1
######################################################################## 100.0%
WARNING: checksums are currently disabled for node.js v4.0 and later
Now using node v4.2.1 (npm v2.14.7)
curiosity:react-youtube-player gajus$ npm install salita -g
npm ERR! Darwin 15.0.0
npm ERR! argv "/Users/gajus/.nvm/versions/node/v4.2.1/bin/node" "/Users/gajus/.nvm/versions/node/v4.2.1/bin/npm" "install" "salita" "-g"
npm ERR! node v4.2.1
npm ERR! npm  v2.14.7
npm ERR! path /Users/gajus/.nvm/versions/node/v4.2.1/lib/node_modules/salita/node bin/salita
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall chmod

npm ERR! enoent ENOENT: no such file or directory, chmod '/Users/gajus/.nvm/versions/node/v4.2.1/lib/node_modules/salita/node bin/salita'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/gajus/Documents/dev/gajus/react-youtube-player/npm-debug.log

Should this package make destructive edits by default?

Wondering if actually making changes to package.json should be protected behind a command line flag. It seems too easy to be destructive just by typing salita.

Enhancement: Specify which areas of package to upgrade

It would be nice to have some method to be able to specify which areas of package should be upgraded.

Something like --dep for Dependencies, --dev for Development Dependencies and so on

Not sure what this error means

I just tried Salita and got the following error message:

salita --check
returns the same error, same line numbers, same stack trace

Working Repository/Directory information is redacted, but I don't think it's relevant.
Windows 7x64
NPM v3.5.3
Salita v0.8.5

No compatible version found: npm@'v3.x-next'

On the latest NodeJS release, v.4 I have this issue when trying to install salita:

npm ERR! Darwin 14.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "salita" "-g"
npm ERR! node v4.0.0
npm ERR! npm  v2.14.2
npm ERR! code ETARGET

npm ERR! notarget No compatible version found: npm@'v3.x-next'
npm ERR! notarget Valid install targets:
npm ERR! notarget ["1.1.25","1.2.32","1.3.2","1.3.4","1.2.20","1.2.21","1.2.22","1.2.23","1.2.24","1.2.25","1.2.27","1.2.28","1.2.30","1.2.31","1.3.0","1.3.1","1.2.19","1.1.70","1.1.71","1.3.5","1.3.6","1.3.7","1.3.8","1.3.9","1.3.10","1.3.11","1.3.12","1.3.13","1.3.14","1.3.15","1.3.16","1.3.17","1.3.18","1.3.20","1.3.21","1.3.22","1.3.23","1.3.24","1.3.25","1.3.26","1.4.0","1.4.1","1.4.2","1.4.3","1.4.4","1.4.5","1.4.6","1.4.7","1.4.8","1.4.9","1.4.10","1.4.11","1.4.12","1.4.13","1.4.14","1.4.15","1.4.16","1.2.8000","1.4.17","1.4.18","1.4.19","1.5.0-alpha-0","1.5.0-alpha-1","1.4.20","1.5.0-alpha-2","1.4.21","1.5.0-alpha-3","1.5.0-alpha-4","2.0.0-alpha-5","1.4.22","1.4.23","2.0.0-alpha.6.0","1.4.24","2.0.0-alpha.6","2.0.0-alpha.7","2.0.0-beta.0","1.4.25","2.0.0-beta.1","1.4.26","2.0.0-beta.2","1.4.27","2.0.0-beta.3","1.4.28","2.0.0","2.0.1","2.0.2","2.1.0","2.1.1","2.1.2","2.1.3","2.1.4","2.1.5","2.1.6","2.1.7","2.1.8","2.1.9","2.1.10","2.1.11","2.1.12","2.1.13","2.1.14","2.1.15","2.1.16","2.1.17","2.1.18","2.2.0","2.3.0","2.4.0","2.4.1","2.5.0","2.5.1","2.6.0","2.6.1","2.7.0","2.7.1","2.7.2","2.7.3","2.7.4","2.7.5","2.7.6","2.8.0","2.8.1","2.8.2","2.8.3","2.8.4","2.9.0","2.9.1","2.10.0","2.10.1","2.11.0","2.11.1","2.11.2","2.11.3","2.12.0","3.0.0","2.12.1","2.13.0","3.1.0","2.13.1","3.1.1","3.1.2","2.13.2","3.1.3","2.13.3","3.2.0","2.13.4","3.2.1","2.13.5","3.2.2","2.14.0","3.3.0","2.14.1","2.14.2","3.3.1","2.14.3","3.3.2","2.14.4","3.3.3","2.14.5","3.3.4"]
npm ERR! notarget 
npm ERR! notarget This is most likely not a problem with npm itself.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.
npm ERR! notarget 
npm ERR! notarget It was specified as a dependency of 'salita'
npm ERR! notarget

Enhancement: `--pin` (or some option) to change `latest` to actual current version numbers

I really like this project. However, often when writing projects, I don't actually look up the current version number of a module and I just set it to latest. When I am ready to publish though, I change latest to the version number of the module that I have been writing and testing with.

I would like an option like --pin that changes all the latest values to their current version. I didn't find a way to do this currently with salita? If I haven't missed how it can be currently done, could an option like this be considered?

Tool reports same versions as updates

I am using salita -o and I don't want to use the --ignore-pegged flag as I do want pegged packages to be reported if there are updates. But I get these types of updates which I don't think are valid:

 Changed:   browser-sync  from  2.26.3  to  ^2.26.3
 Changed:   http-server   from  0.11.1  to  ^0.11.1
 Changed:   husky         from  1.3.1   to  ^1.3.1

My package.json does include

  "devDependencies": {
    "browser-sync": "2.26.3",
    "http-server": "0.11.1",
    "husky": "1.3.1"
  }