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

[pksjce]

TODOS

Migrations

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

NFR

• Tests should pass
• Add yarn support
• 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

[TheLarkInn]

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.

[pksjce]

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

[DanielaValero]

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

[pksjce]

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.

[DanielaValero]

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

[pksjce]

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

[evenstensberg]

/example should be removed in the future @pksjce

[okonet]

I've started some work in #40

Let's coordinate the effort. I'm just going the list of open items for now.

[pksjce]

Closing this issue.

[okonet]

I don't think it should be closed. It is still only works with the hard coded example.

[TheLarkInn]

Alright nice work everyone, I'm going to take this for a ride. I'll report back!

[evenstensberg]

Status on this @okonet @pksjce ?

[okonet]

Closing. See #40