docs: update ember-addon example

[ndekeister-us]

Not really important and very specific to ember-addon example, but if we put validatePeerDependencies check in init method, then we will not be able to generate addon blueprints, the check will fails because peerDependencies will not be found

It is an unwanted behavior as, most of the time, ember-addon blueprints will automatically install peerDependencies. Putting the check in included hook allows blueprints to be run correctly and throws error when building/serving the project if peerDependencies are not found

Current behavior with init method ->

[hjdivad]

Seems fine to me.

@rwjblue do you see any issue with recommending validation occur in included rather than init?

[rwjblue]

I think using included could be fine, but IMHO it isn't a straight up replacement. There are a number of scenarios where you wouldn't be doing a build, but still want to validate (e.g. running tests with a prebuilt dist, adding your own commands, etc).

Maybe instead of replacing, we could add both examples and indicate the pros/cons of each?

[rwjblue]

if we put validatePeerDependencies check in init method, then we will not be able to generate addon blueprints, the check will fails because peerDependencies will not be found

I don't fully understand this @ndekeister-us, can you explain further? As you mentioned, most blueprints will automatically add the required peer dependencies for you; at which point I would expect the validation in init to actually work just fine?

[rwjblue]

Ah, I see. The blueprint hasn't been run yet (in the demo), so it hasn't had a chance to install the required peer dependencies.

[rwjblue]

I think it's probably possible to know that the blueprint is being ran, and choose not to validate. But I think documenting and using included is just going to be simpler to explain (and easier to get right).

[ndekeister-us]

Documented the included hook example (but feel free to edit if it is not clear)

[hjdivad]

Thanks @ndekeister-us!