Install dependencies described in releases

[jfmengels]

Follows the same train of though as #1.

I think it would be nice if in the provided releases array, we added support for additional dependencies to install (maybe even remove?).

[{
    "version": "0.14.0",
    "dependencies": [
        "react-dom@^0.14"
    ],
    "transforms": [
        "path/to/transorm/a.js",
        "path/to/transorm/b.js"
    ]
}]

For instance, in React v0.14, the module was split into two separate modules: react and react-dom. A similar thing happened with Babel v6.

[jamestalmage]

My only thought would be that this represents a pretty big expansion of the project scope, and that it is going to be hard to get right.

Instead of trying to accomplish all this via json, what if we just provided a callback API

[sindresorhus]

Yeah, provide a hook of some kind and provide utility methods to make common tasks easy to accomplish.

[jfmengels]

So you guys are thinking more of something like this?

#!/usr/bin/env node
'use strict';

var upgrader = require('lib-upgrader');
var pkg = require('./package.json');
var releases = require('./releases.json');

var options = {
    libraryName: 'Your library name',
    releases: releases,
    pkg: pkg,
    dirname: __dirname
};
upgrader.applyCodemods(options)
  .then(function(result) {
    return upgrader.updateDependencies(options);
  })
  .then(function(result) {
    return upgrader.otherProvidedFunctionality(options);
  });

(we could support both Promises and callbacks with an optional callback parameter)

[jamestalmage]

Yes, that API looks much more flexible. As we create features that are useful on their own, let's split them out to their own modules. lib-upgrader can serve as a sort of aggregate tool chain.

I would just do promises via babel-register/babel-polyfill. I believe jscodeshift already loads babel-register anyways (you can use es2015 in your codemods). I think they may still be on Babel 5 though.