ci: migration to CircleCI 2

[ghost]

Since CircleCI 1 will be retired August 31th, I've done a couple of things (based on #1264 initial work) to achieve at least a first version of this migration.

Done

• As DRY as possible.
• Test-reporting when no additional code was needed.
• Parallel running.
• Build-matrix against multiple node versions (currently 8:latest and 10:latest).
• Drops old circle.yml file.

To be done (or not)

• Test reporting for jasmine tasks (?)
• Coverage reporting (?)

Additional Notes

I've upgraded eslint and eslint-plugin-vue-libs to Vue versions (junit reporter was slightly broken in previous eslint version) and some files were fixed in the process.

[ktsn]

Do we really need to run on both Node 8 and 10? Since Vuex is a library for frontend, I think it would be enough to run on one version of Node.

[ghost]

Of course! I've updated the configuration accordingly.

[ktsn]

LGTM. Thank you!

[DanielRuf]

Well, Node.js 10 includes (breaking) changes so testing both does make much sense (the build environment is still important).

[DanielRuf]

To be clear, CI is not just about testing the released product but also testing if the complete toolchain will work (please don't forget the contributors who use Node.js 10 - otherwise it may happen that incompatible dependencies could produce a broken build or cause unforeseen bugs - and there are many - especially well known tools like Grunt and others).

[ktsn]

I see where you are coming from. To be honest, it however is too much for Vuex for me.

Of cause it would be better that we can test all possible cases but it would make ci testing slower and complicated, and may suffer our DX.

On the other point of view, I guess there would not be so much cases that changing Node.js version breaks Vuex workflow as we use it only for tooling and testing. Also it would not be so critical. I'm not sure that we should add extra workflow to test such small risk with the cost.

[DanielRuf]

Slower? Not really as you can test in parallel, if this is not yet know. It requires a specific configuration.

The risk is not so small as I have caught issues in big projects thanks to a Node.js 10 setup which broke the projects for contributors and users.

If you are confident that there will be no problems (I would never be) you can keep it as is and hope that people report the issues that appear on Node.js 10 (and very soon 11).