These bindings can be replaced wholesale with the more idiomatic
alternative: aliases.
In addition, avoid passing in user to components where it can be injected directly.
One of the perceived downsides of dependency injection can be
that it can make debugging feel more difficult because it's not
immediately clear where the value is coming from, which the explicit
variant we previously used does not suffer from. It might also be
argued that we also lose out on a seam that could be useful in the
future where a component doesn't care about the specific type of
user, just that one is passed in.
While explicitness is often a virtue, it comes at the cost of increased
noise that pervades multiple layers of components. I'd argue this makes
the parent components more difficult to understand, given they are
littered with unnecessary references to data they themselves do not
need.
This decreases the noise/ceremony around accessing
userPermissions/auth data and restricts access to that data to
the child components that actually need to know about it.
As to losing a seam, it appears 1) that this isn't
currently necessary and 2) we can use an internal computed
property should the need arise in the future.
This upgrades several Ember-CLI related packages, but does not change
our Ember/Ember-Data versions (those will require code changes that are
best handled in separate commits).
In addition, Testem can now be dynamically configured, meaning we no longer need
custom scripts to run as part of CI to set dynamic launcher configuration values
based on PR status.
Some POD parsers recognize only lowercase format names.
For e.g., pod2markdown fails to generate a markdown file with the status image if the format is 'HTML'
