Remove local fork of yeoman

[evenstensberg]

Need an update from @pksjce on the bug she was complaining about recast. Moving to yeoman generators, so this needs to be resolved.

For the yeoman fork, this is removed and replaced in #148

[thescientist13]

it appears this would address / resolve #132

[evenstensberg]

Probably, but not entierly sure

[evenstensberg]

This is underway at #207 , yeoman might be trickier

[mischkl]

The git dependency is causing our build to act up due to our proxy on some systems. ☹️ One more reason it would be great to get rid of the local fork dependency of yeoman as soon as possible! 😉

[evenstensberg]

Haha yeah working on it, but need to come up with a good workaround. There's a possibility we'll need to create a temporary .yo config file for each scaffold, which shouldn't be be necessary ..

[kim-10e]

We just ran into this issue too:

yarn install v0.27.5
[1/4] Resolving packages...
[2/4] Fetching packages...
error An unexpected error occurred: "https://codeload.github.com/ev1stensberg/generator/tar.gz/9e24fa31c85302ca1145ae34fc68b4f133251ca0: Request failed \"400 Bad Request\"".
info If you think this is a bug, please open a bug report with the information provided in "/Users/kimburgaard/dev/10e/release/build/enterprise-client/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

The workaround to get around this was to manually delete the yeoman-generator entry in our yarn.lock file and run yarn again.

Dependencies like these outside of the npm/yarn registries make me super uneasy for a couple of reasons. For one, npm learned the hard way to never allow publicly published packages to be deleted because it breaks dependents, and it requires more oversight to understand where all the 3rd party code comes from.

[andrewpmontgomery]

#313 and #314 are both similar. Reverting to webpack-fork-yeoman-generator would fix the problem.