Webpack-cli: Feature [--migrate]: Migrate from webpack 1 to 2 through webpack-cli

Created on 20 Dec 2016 · 13Comments · Source: webpack/webpack-cli

TODOS

Migrations

[x] loaders -> rules
[x] pre/postLoaders -> rules with enforce: 'pre/post'
[X] solve for -loaders suffix.
[x] resolve.root -> resolve.modules
[ ] remove json-loader
[x] add sourceMap: true to UglifyJsPlugin
[x] change ExtractTextPlugin syntax
[x] remove OccurendeOrderPlugin
[ ] add LoaderOptionsPlugin with minimize:true ,context and debug

NFR

[x] Tests should pass
[ ] Add yarn support
[x] Add node 4 support

Do you want to request a feature or report a bug?
This is a feature request

What is the current behavior?
There is no automated tool to help migrate from webpack 1 to webpack 2.

If the current behavior is a bug, please provide the steps to reproduce.
NA

What is the expected behavior?
The expected behavior is to have webpack-cli help make this migration automatically.

If this is a feature request, what is motivation or use case for changing the behavior?
It is not clear from first glance as to what it takes to migrate breaking features for webpack2. Providing an automated option would be the best case scenario

Please mention other relevant information such as the browser version, Node.js version, Operating System and programming language.

Node.js version > 0.12.17

AST Transform

Source

pksjce

All 13 comments

Maybe we could create a schema diff map. (At least for future builds) v3, 4, etc. Then we could literally map values and pieces to v3 schema etc.

Obvs a down the road feature but still relevant.

TheLarkInn on 21 Dec 2016

Yes, I'm really not sure what webpack1 schema was and so I'm pretty sure I will miss many cases while doing this.

pksjce on 23 Dec 2016

I think we should add explicitly the task that we should validate the current webpack 1 config, and the generated webpack 2 config. This way we would avoid problems during the migration and ensure that the result is working fine

DanielaValero on 3 Jan 2017

Plan of action

webpack --migrate <transformation(optional)>

This would then work as follows.

switch (arg1) {
  // other cases
  case 'migrate': 
    cliEngine.migrate(..restOfArgs);
    break;
}

Migration logic

cliEngine.js

const migrate = chosenTransforms => {
  const currentConfig = readCurrentWebpackConfig();
  var expectedConfig = makeCopyOf(currentConfig);

  /* jscodeshift api is usually represented by variable j
      will find and apply transformations */
  const j = api.jscodeshift;
  const transforms = getRelevantTransforms(chosenTransforms);
  /* mutates the copied webpack config  */
  const ast = j(expectedConfig);
  const output = applyTransforms(transforms, ast);
  const isUserFineWithChanges = validateAndshowTheCodeDiffs()
  if (isUserFineWithChanges) {
    displayPrettyOutput(output, ast.toSource())
  } else  {
    abortOrRetryProcedure()
  }
}

const getRelevantTransforms = chosenTransforms => {
  const allTransformFns = getAllTransforms();
  /* May need some logic */
  const filteredTransformFns = allTransformFns.filter(chosenTransforms);
  return filteredTransformFns;
}

const applyTransforms = (transformFns, ast) {
  let output = [];
  /* ast is being mutated as global variable
      But each transformation can send out its own output of errors/success/code-diff/logs etc */
  transformFns.forEach(fn => output.push(fn(ast)));
  return output;
}

Transformations

Each transformation is an independent mutation of code. It should tackle a bare minimum of mutation and must work under all possible circumstances. The out of the box testing of jscodeshift should help with this.

---transformations
|
| ---transform1
| |---__tests__
| |---__testfixtures__(contains input and expected output)
| |--- transform1.js

transform1.js

export default ast => {
  return ast.findStuff()
             .forEach(doStuff);
}

Transform Utils

[TODO]
We need utility functions for easy manipulation in the context of webpack's schema.

createUtils - create a loader, create a plugin, create entrypoints etc
findUtils - findResolveOptions, findLoaderQuerys etc
replaceUtils - replaceModuleWithRules etc.

@DanielaValero - This is basically what I plan to implement under this issue. I will first write the raw transformers so that I get passing tests for all possible input config scenarios. After that we can create common utils and refactor with the assurance of the test beds.

pksjce on 4 Jan 2017

Hello @pksjce thanks a lot for the detailed explanation! Now is clearer what you intend to do. I will dig soon deeper into this, so I can be more useful with the code reviews and picking up any task.

At a point, would be good when we migrated some of the documentation you added in your comment into some relevant place in the code, so the explanations don't get lost, and others can consume them after this issue is closed and lost of our radar

DanielaValero on 4 Jan 2017

Yes, I will try to adequately transfer this knowledge to the code. You also be on the lookout during reviews.

pksjce on 4 Jan 2017

👍1

/example should be removed in the future @pksjce