Integrate Webpack Validator Into Webpack.Config.js

[LukeSheard]

Closes #367 by warning the user of any errors that occur within the webpack config. In particular this is useful for anyone who integrates gatsby-node/modifyWebpackConfig into their workflow to watch for errors that occur from misuse of merging and configuring custom setups when it comes to build time.

The issue brought up by this is that many of the packages required warn about a Node Version less than 4.0.0. Travis shows that all the tests fail on the Node 0.12.x versions.

[KyleAMathews]

I'd be ok bumping our minimum required node version to 4. Older versions are about to be unsupported in any case.

[LukeSheard]

Sure. I guess this will mean a minor release to 0.13, so I've updated the error message to reflect that. You can change that though if you want.

[KyleAMathews]

Code looks great! Will give more through review + make release in a couple days when done traveling.

Could you post an example of what an error message looks like?

/cc @kentcdodds

[benstepp]

If the user does not return a webpack configurator object here the subsequent calls to exportedWebpackConfig.resolve() will throw a TypeError: Cannot read property 'resolve' of undefined

[benstepp]

I think a couple of console.log's are left over.

What is going on with the notAbsolutePath?

Otherwise looks good.

---

Just a late night idea with poor naming. If this was in it's own file with an optional function argument that defaulted to the user's modification function, you could run unit tests with various config objects and modifyWebpackConfigs to ensure the correct errors are being returned given certain user changes to the config. I would stray away from testing the libraries in use, but rather check that the user never sees errors that are internal.

// modifyWebpackConfig try catch here
export default function ModifyAndValidateUserChangesToConfig(config, modifyWebpackConfig = modifyWebpackConfig) {
  // do all the things
  return config
}

[LukeSheard]

@benstepp The notAbsolute path error is because webpack-validator doesn't allow for absolute paths and there's no option in the configuration to allow that from the documentation or source code. Since Gatsby relies on absolute paths I ignore those if there are any.

I'll modify the PR to use a ModifyAndValidateUserChangesToConfig for now though?

[LukeSheard]

Is it further worth splitting the webpack.config internal functions into separate files as well for easier digestion? Eg:

webpack.config/
    output.js
    entry.js
    ...

[benstepp]

I'd leave the rest of the webpack.config for now to keep the changes small, focused, and easy to understand.

I went ahead and checked out your changes and it seems the validator error occurs because gatsby adds a path to resolveLoader.root that doesn't exist on the filesystem. The problem exists here on line 433.

I feel like it would be better to extract resolveLoader into a function like everything else and do a fs.statSync for the folder before adding it. This way it's a little more clear about what is happening, we might gain some performance by reducing webpack scope, and we aren't suppressing errors that may benefit the user from webpack-validator.