1 | Also check out:
|
2 |
|
3 | * [next-updater](https://github.com/bahmutov/next-updater) can update all your repos
|
4 | * [dont-break](https://github.com/bahmutov/dont-break)
|
5 | that checks if your code is going to break everyone who depends on it.
|
6 | * [changed-log](https://github.com/bahmutov/changed-log) returns commit messages for
|
7 | the given NPM package or Github repo between two tags.
|
8 |
|
9 | ## Example
|
10 |
|
11 | Imagine your nodejs module *foo* has the following dependencies listed in *package.json*
|
12 |
|
13 | "dependencies": {
|
14 | "lodash": "~1.2.0",
|
15 | "async": "~0.2.5"
|
16 | }
|
17 |
|
18 | You would like to update lodash and async to latest versions, to not sure if
|
19 | this would break anything. With *next-update* it is easy: run command `next-update`
|
20 | in the folder with module *foo*. Here is the example output:
|
21 |
|
22 | next updates:
|
23 | lodash
|
24 | 1.2.1 PASS
|
25 | async
|
26 | 0.2.6 PASS
|
27 | 0.2.7 PASS
|
28 | 0.2.8 PASS
|
29 |
|
30 |
|
31 | Both *package.json* file and *node_modules* folder are left unchanged,
|
32 | and now you know that you can safely upgrade both libraries to later versions.
|
33 |
|
34 | ### It even tells you the install command ;)
|
35 |
|
36 | Use the following command to install working versions
|
37 | npm install --save lodash@2.1.0
|
38 |
|
39 | This might not appear like a big deal for a single module that is using
|
40 | popular 3rd party libraries with stable apis only. *next-update* is most useful
|
41 | in the larger development context, where multiple modules are being developed
|
42 | side by side, often by different teams. In such situations, checking if an upgrade
|
43 | is possible could be part of the continuous build pipeline.
|
44 |
|
45 | You can see if your dependencies are out of date by using
|
46 | [david](https://david-dm.org),
|
47 | it even has badges you can add to your README files.
|
48 |
|
49 | *next-update* reports the probability of success for a given dependency update using
|
50 | anonymous global statistics from [next-update](http://next-update.herokuapp.com/) server
|
51 |
|
52 | ```
|
53 | available updates:
|
54 | package available from version average success % successful updates failed updates
|
55 | -------------------- --------- ------------ ----------------- ------------------ --------------
|
56 | grunt-contrib-jshint 0.8.0 0.7.2 100% 34 0
|
57 | grunt-bump 0.0.13 0.0.12 100% 4 0
|
58 | ```
|
59 |
|
60 | ## Install
|
61 |
|
62 | npm install -g next-update // installs module globally
|
63 | next-update --help // shows command line options
|
64 |
|
65 | ## Anonymous usage collection
|
66 |
|
67 | After testing each module A upgrade from version X to Y, *next-update* sends
|
68 | anonymous result to [http://next-update.herokuapp.com/](http://next-update.herokuapp.com/).
|
69 | The only information transmitted is:
|
70 |
|
71 | ```json
|
72 | {
|
73 | "name": "lodash",
|
74 | "from": "1.0.0",
|
75 | "to": "2.0.0",
|
76 | "success": true
|
77 | }
|
78 | ```
|
79 |
|
80 | This information is used to answer the following questions later:
|
81 | what is the probability module A can be upgraded from X to Y?
|
82 | Thus even if you do not have tests covering this particular module,
|
83 | you can judge how compatible version X and Y really are over the entire
|
84 | internet.
|
85 |
|
86 | You can inspect data send in
|
87 | [stats.js](https://github.com/bahmutov/next-update/blob/master/src/stats.js).
|
88 |
|
89 | If the dependency module has been upgraded by anyone else, its statistics
|
90 | will be displayed with each test.
|
91 |
|
92 | ```sh
|
93 | stats: deps-ok 0.0.7 -> 0.0.8 success probability 44.44% 8 success(es) 10 failure(s)
|
94 | ```
|
95 |
|
96 | A lot of NPM modules [do not have tests](http://npmt.abru.pt/), but
|
97 | at least you can judge if someone else has success going from verion X to version Y
|
98 | of a dependency.
|
99 |
|
100 | ## Use
|
101 |
|
102 | Make sure the target module has unit / integration tests,
|
103 | and the tests can be run using `npm test` command.
|
104 |
|
105 | Run `next-update` from the command line in the same folder as
|
106 | the target module. In general this tool does the following:
|
107 |
|
108 | 1. Reads the module's dependencies (including dev) and their versions
|
109 | 2. Queries npm registry to see if there are newer versions
|
110 | 3. For each dependency that has newer versions available:
|
111 | 1. Installs each version
|
112 | 2. Runs command `npm test` to determine if the new version breaks the tests
|
113 | 3. Installs back the current version.
|
114 | 4. Reports results
|
115 |
|
116 | ### Misc
|
117 |
|
118 | * To see what has changed in the latest version of any module,
|
119 | use my companion tool [changed](https://npmjs.org/package/changed)
|
120 | like this `changed foo` (*foo* is package name)
|
121 | * When comparing versions, keywords *latest* and *** are both assumed to equal to "0.0.0".
|
122 | * A good workflow using *next-update*
|
123 | * see available new versions `next-update --available`
|
124 | * check latest version of each module using `next-update --latest`
|
125 | * install new versions of the desired modules using standard `npm i dependency@version --save`
|
126 | * You can use custom test command, for example `next-update -t "grunt test"`
|
127 | * `npm test` is used by default.
|
128 | * You can keep each working version in package.json by using `--keep` flag.
|