no issue
- ran [ember-native-class-codemod](https://github.com/ember-codemods/ember-native-class-codemod) to convert the majority of remaining EmberObject based controllers and components to native class syntax using the `@classic` decorator
- skipped older style modal components (`components/modal-*.js`) due to observed incompatibilities in some cases
no issue
- ran [es5-getter-ember-codemod](https://github.com/rondale-sc/es5-getter-ember-codemod)
- [es5 getters RFC](https://github.com/emberjs/rfcs/blob/master/text/0281-es5-getters.md)
- updates the majority of `object.get('property')` with `object.property` with exceptions:
- `.get('nested.property')` - it's not possible to determine if this is relying on "safe" path chaining for when `nested` doesn't exist
- `.get('config.x')` and `.get('settings.x')` - both our `config` and `settings` services are proxy objects which do not support es5 getters
- this PR is not exhaustive, there are still a number of places where `.get('service.foo')` and similar could be replaced but it gets us a long way there in a quick and automated fashion
no issue
Automated tools, code generators, and editor integrations are increasingly standardising on the import style used in `ember-modules-codemod`. Our import style differed a little with regards to service/controller injection imports which meant we were starting to see inconsistent naming.
no issue
- add eslint-plugin-ember, configure no-old-shims rule
- run `eslint --fix` on `app`, `lib`, `mirage`, and `tests` to move imports to the new module imports
- further cleanup of Ember globals usage
- remove event-dispatcher initializer now that `canDispatchToEventManager` is deprecated
no issue
- add ember-suave dependency
- upgrade grunt-jscs dependency
- add a new .jscsrc for the client's tests directory that extends from client's base .jscsrc
- separate client tests in Gruntfile jscs task so they pick up the test's .jscsrc
- standardize es6 usage across client
closes#5903, refs #5409
- switch alert/notification component tests from unit to integration where appropriate
- rename `notifications.closeAll` to `notifications.clearAll` to better represent it's behaviour
- add concept of a "key" to alerts/notifications and ability to close only specified keys through notifications service
- close duplicate alerts/notifications before showing a new one
- specify a key for all existing alerts
- close failure alerts on successful retries
- clear all currently displayed alerts on successful sign-in
issue #5409
- change persistent/passive notification status to alert/notification
- replace showSuccess/Info/Warn/Error with showNotification/showAlert
- fix and clean up notification/alert components
No Issue
- Switches to the newer style of dependency injection.
- Instead of injection Controllers via "needs," use
Ember.inject.controller().
- Get rid of initializers that were only injecting objects
into various factories. Converts these objects into Ember.Service
objects and declaratively inject them where needed via
Ember.inject.service(). The added benefit to this is that it's no
longer a mystery where these properties/methods come from and it's
straightforward to inject them where needed.
