toss @polkadot/dev after extracting out relevant configs and deps from it

[pmespresso]

so we don't have extraneous dependencies and don't run into hoisting issues in future

[amaury1093]

Initially I wanted to try react-scripts, to see if it's compatible with our TS projects, so that the overhead of bumping packages in polkadot-js/dev(-react), and making sure each bump doesn't break anything, is done and tested by facebook, not by us.

So basically:

• @polkadot/dev = react-scripts + typescript + some babel plugins + some other packages for internal maintenance
• @polkadot/dev-react = @polkadot/dev + styled-components + enzyme

Inside @polkadot/dev, all the polkadot-dev-* scripts will stay the same, but use package versions (jest, webpack, babel) dictated by react-scripts.

• Packages like api, common or tools will obviously not use react-scripts build|start|test, but polkadot-dev-* scripts directly.
• Packages like apps or light-apps here will use react-scripts build|start|test included in @polkadot/dev.

---

Above is an ideal future (imo), but today we're not there, and having both is apparently a headache. We have 2 solutions:

1. drop @polkadot/dev, and follow react-scripts.
   • we could create a dev/ package inside this repo, which will be react-scripts + typescript + the minimal amount of packages to make this whole thing work. And if the above long-term scenario sounds good to you @jacogr @yjkimjunior, then we could move this dev/ to @polkadot/dev
   • downside: there'll be 2 dev/s for a while.
2. drop react-scripts, and do the same as @polkadot/apps
   • no config, everything will work (we rely on Jaco bumping the packages)
   • any project using @polkadot/dev + CRA will have a headache, we stray away from CRA

I prefer 1, but I'm open to 2 too for consistency between Parity projects, and revisit when react-scripts becomes more suited for TS.

[pmespresso]

+1 for 1