Complete Upgrade: Babel 6 / React 0.14.x / Node 5.4/ react-transform-hmr / all dependencies are up to date

[bartekus]

Surface Upgrade Completed:

• Babel 6
• React 0.14.x
• Node 5.4
• react-hot-loader (deprecated) replaced with react-transform-hmr

Webpack Modification (WIP)

• webpack.config.coverage.js

  "isparta?{ babel: { stage: 2 } }"
  replaced with:
  "isparta?{babel}"
  not optimal, given that currently there is only one .babelrc config utilizing es2015, react & stage-1

• webpack.config.hot.js

  ["react-hot", "babel-loader?optional=runtime&stage=2"]
  replaced with:
  ["babel"]
  not optimal as described above + address babel-runtime

• webpack.config.js

  ["babel-loader?optional=runtime&stage=2"]
  replaced with:
  ["babel"]
  critical since base webpack config is used in tests

Environment specific

Node 0.10 / 0.12
replace with:
Node 5.4

NPM 2.1.x
replaced with:
NPM 3.3.x

• Intended to bring Node / NPM to most current versions

TODO:

Structural Code Modification needed on:
/client/components/error-panel.jsx
/client/components/output-panel.jsx
/client/components/types.jsx

Currently not React 0.14.x compliant which results in:
TypeError: ... Property value of JSXAttribute expected node to be of a type ['JSXElement','StringLiteral','JSXExpressionContainer'] but instead got 'CallExpression'

[bartekus]

Work-In-Progress - Submittal for reference as objections/suggestions are addressed.

[ryan-roemer]

Please remove trailing commas.

[ryan-roemer]

@bartekus -- Thanks for the initial WIP work! I've got a few preliminary comments.

Also, I think the eslint-* stuff may need updates for modern configs / rules. Also, the fs.access is a library depending now on 0.12+ node, so you may need to pin that library specifically to an earlier version.

Ultimately, get CI cleaned up such that it correctly runs on your machine. The last stuff with Karma through Sauce will fail because Travis won't allow you to use this repo's secret credentials via a forked PR (I'll hook up that last part when we're at that stage of the process).

[bartekus]

• I've recombined all webpack configs into one and adjusted package.json to utilize

NODE_ENV=/*mode*/

in order to trigger them.

I've also removed .babelrc and moved the setting to webpack.config.

• Currently karma has been separated from the webpack however it's my intention to have only one config file hence I'll be merging it into back into webpack.config.js and then refactor it to make it concise and clean. As with webpack, the NODE_ENV will be used to trigger appropriate build.
• I've adjusted and corrected all errors but TypeError in:
  /client/components/error-panel.jsx
  /client/components/output-panel.jsx
  /client/components/types.jsx

Property value of JSXAttribute expected node to be of a type ['JSXElement','StringLiteral','JSXExpressionContainer'] but instead got 'CallExpression': 

These are the last 3 errors (+ 2 warnings) present that I can spot by npm run check && npm run dev
I have tried to fix them by adding constructor/super but so far I have not had any success thus far so I'll require some pointers to bring this into finalization.

As to linting standards:
https://github.com/feross/standard
or
https://github.com/Flet/semistandard
would provide solid base.
Personally I'm for the later, since I do like ;

[ryan-roemer]

@bartekus -- I think it's perhaps better to focus on just the upgrade. Offhand, a couple of things to keep in mind:

• We're going to use the existing eslint configs, but updated to modern https://github.com/walmartlabs/eslint-config-defaults/tree/master/configurations/walmart -- we help maintain these and have deep experience and familiarity with these over many, many projects.
• Please keep the webpack configs separate from the karma configs. This enables much better workflows that have webpack dev processes running in a separate process from the karma one. And in large file projects, the webpack build time is non-trivial.
• Very soon, we are going to be moving all the eslint, karma, webpack, and other configs to a builder archetype (analogous to `builder-react-component archetype, but for a full react-based application server) for better management of dependencies, workflows and honing down all the boilerplate in this specific project.

Ideally, the best approach, infrastructure-wise is "change the structure of files" + "touch things" as little as possible.

[ryan-roemer]

Is this an actual version? (Sorry if I led you astray, I was giving pseudocode in earlier comment)