[ENHANCEMENT] Add podModulePrefix deprecation for generate and destroy commands

[trabus]

This PR fulfills #3424 by adding deprecation warnings for generate and destroy commands, as well as bumping the ember-resolver version to 0.1.14.

The deprecation warnings were not using the ui, so I added an additional version of deprecate that allows you to pass the ui in. I also changed cli.run() so it returns an object containing the ui so we can now check the ui inside of acceptance tests. So now inside any ember-cli acceptance test you need to check the ui output by doing the following:

it('outputs ui text', function() {
  ember(['new','my-app']).then(function(result){
    expect(result.ui.output).to.include('new');
  });
});

[rwjblue]

Had to release 0.1.14 to fix an issue, can you bump to that?

[rwjblue]

The message says breaking, but this doesn't seem to actually break anything (but rather it deprecates and keeps everything functional). Am I mis-interpreting something?

[trabus]

@rwjblue You're right, I'll remove 'breaking'. I was more going for the fact that people will need to change their setups if they're using podModulePrefix to not get the warning, so I was counting that as breaking.

[trabus]

@rwjblue @stefanpenner I just wanted to make sure this was okay before you merge, it doesn't seem to be breaking anything by returning this object instead of just the exitCode.

[rwjblue]

LGTM

[trabus]

Ugh, random AppVeyor timeout, I don't know why it hates me so.

[rwjblue]

restarted build

[trabus]

Looks like more random timeouts.

[rwjblue]

LGTM

@stefanpenner - r?

[rwjblue]

Actually, I think we need to handle falsey exit codes 0 is an exit code and is falsey.

Something like:

var exitCode = typeof result === 'object' ? result.exitCode : result;

exit(exitCode);

[stefanpenner]

I'm nervous to make changes in this file, as it is shared between multiple versions of ember-cli and lasts a long time, can we avoid it?

[rwjblue]

This file's change should be perfectly backwards compatible (we allow for result to either be an object (new thing) or a number (old thing)). We should add a comment saying why we are doing the ternary (and what version it was added in so we know when we can remove it).

@stefanpenner - In theory we could avoid changing this file, but then we could not test the UI output in acceptance tests...

[trabus]

I was too, but providing access to the ui for testing is definitely worth it IMO. This change essentially makes returning an object possible while still returning the exitCode.

[trabus]

I'll gladly add a comment explaining what this does and why, with reference to cli.js

[stefanpenner]

I was too, but providing access to the ui for testing is definitely worth it IMO. This change essentially makes returning an object possible while still returning the exitCode.

I believe this is in-fact worth it. I just wanted to be confident that this was thoroughly taken into account. I am happy with this.

[trabus]

@stefanpenner did you want me to put in the comment, or is this good as-is?

[stefanpenner]

good as-is. If at some-point someone whats to add this to the architecture.md that would be lovely.

[trabus]

@rwjblue @stefanpenner I think this is ready to go. Let me know if you want anything else done on it.

[trabus]

@rwjblue I'll get a PR going to reflect this in the docs to go with the next release. When are we planning to release 0.2.1?