Fix CI: update yeoman-generator to 3.x, apply latest prettier formatting

[virkt25]

Make master go green again by:

Commit 1

• Updating yeoman-generator to 3.x
  • Updating CLI tests as needed

---

Commit 2

• Applying latest prettier formatting standards
  • Empty properties in front-matter have been removed.

Checklist

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

[shimks]

For context, the tests are failing because of the upgrades made between yeoman-generator 2 -> 3. The changes are listed here https://github.com/yeoman/generator/blob/master/lib/index.js#L433, where the error being thrown is emitted AND rejected. In v2, the error was emitted, and then a callback was called with the error. The problem is that in the test helper https://github.com/yeoman/yeoman-test/blob/master/lib/run-context.js#L121, the rejection is emitted AGAIN here.

I've spent hours into trying to fix around the code in yeoman so that the error can just be rejected, but despite being caught in a catch block, it will always show up as an unhandled rejected promise. Alternatively, just emitting the error in favor of rejecting it will make the tests pass as is.

If anybody can see something that I missed that can be fixed in yeoman to address this issue, I'd be super happy know so that I feel my time investment in this issue can be justified :p

I'm just very peeved at yeoman that we have to essentially write our own error-handling system (this.exit) instead of trusting the generator and the testing module to do this for us.

[bajtos]

As I understand expect().to.be.rejectedWith(/regexp/), it works exactly the same way as the new code which you wrote here using .then(onSuccess, onFailure). I personally prefer rejectedWith as it's less code to maintain and makes it more difficult to introduce an error.

What are the reasoning behind this change? Can we revert it please?

[bajtos]

Ditto, can we keep using rejectedWith instead?

[bajtos]

Having to catch errors and report them via this.exit feels ugly to me, but if there isn't any better way, then I can live with it.

[bajtos]

I'm just very peeved at yeoman that we have to essentially write our own error-handling system (this.exit) instead of trusting the generator and the testing module to do this for us.

@shimks could you please add a description of this problem to #844, the issue tracking all issues we have with Yeoman?

Sometimes it makes me wonder how much more difficult things have to get before we agree to get rid of Yeoman.

For context, the tests are failing because of the upgrades made between yeoman-generator 2 -> 3. The changes are listed here https://github.com/yeoman/generator/blob/master/lib/index.js#L433, where the error being thrown is emitted AND rejected. In v2, the error was emitted, and then a callback was called with the error. The problem is that in the test helper https://github.com/yeoman/yeoman-test/blob/master/lib/run-context.js#L121, the rejection is emitted AGAIN here.

I took a quick look. Isn't it possible to install error event handler on the generator instance?

Anyhow, these recent changes in yeoman look wrong to me, I think we should open an issue in yeoman, try to convince yeoman maintainers that the current behavior is not correct and get it fixed (possibly contributing the fix ourselves).

[shimks]

Not sure if my approval would count here, but your latest changes look good to me

[jannyHou]

👍

[bajtos]

👌

[bajtos]

BTW: I changed the pull request title so that it better describe what is being changed. "Fix ci" is not very helpful when you see it as an entry in the list pull requests.

[virkt25]

BTW: I changed the pull request title so that it better describe what is being changed. "Fix ci" is not very helpful when you see it as an entry in the list pull requests.

Thank you for that! I think it just picked up the branch name instead of the commit message because there were multiple commits. I'll be more careful to update the PR Name in the future.