substrate-light-ui
substrate-light-ui copied to clipboard
toss @polkadot/dev after extracting out relevant configs and deps from it
so we don't have extraneous dependencies and don't run into hoisting issues in future
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,commonortoolswill obviously not usereact-scripts build|start|test, butpolkadot-dev-*scripts directly. - Packages like
appsorlight-appshere will usereact-scripts build|start|testincluded 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:
- 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 thisdev/to@polkadot/dev - downside: there'll be 2
dev/s for a while.
- we could create a
- 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.
+1 for 1