Strict versioning of templates downloaded to match npm package.

[walletconnect]

Strict versioning of templates downloaded to match npm package.

[PaulRBerg]

Fantastic idea.

This is why we added a caveat in the README:

If you've previously installed create-eth-app globally via yarn global add create-eth-app, we recommend you uninstall the package using yarn global remove create-eth-app and use the yarn create eth-app shorthand to ensure that you use the last version.

But you're right - as per Hyrum's Law, it's almost guaranteed for someone out there to misuse the API.

[TomAFrench]

Related to this, we can think about exploring how IPFS can be used to stored these templates.

[PaulRBerg]

Implemented in #75.

[PaulRBerg]

I'm reopening this issue because I realised that a strict versioning of templates comes with an undesirable second-order effect.

Say that we release v1.6.0 and it has a bug that makes all templates not run the start script. Well, all users that installed [email protected] globally will forever be stuck with a defect release of our software.

It's true that similar bad things can happen when CEA always pull the templates from the HEAD ref, but in that case we can hot-fix the bugs. And the issue of older versions of CEA not being compatible with the latest HEAD is remediated by adhering to semver - if we make any breaking change, it should be part of a v2 release.

Update

After mulling over this, I think we should proceed with the strict versioning. The upside of determinm is greater than the downside of a potential buggy release.