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
- converted remaining uses of `this.$()` that I could find over to native DOM
- deprecation is still silenced for now because both `liquid-fire` and `liquid-wormhole` trigger it
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
- adds `eslint-plugin-sort-imports-es6-autofix` dependency
- implements ESLint's base `sort-imports` rule but has a distinction in that `import {foo} from 'bar';` is considered `multiple` rather than `single`
- fixes ESLint's autofix behaviour so `eslint --fix` will actually fix the sort order
- updates all unordered import rules by using `eslint --fix`
With the increased number of `import` statements since Ember+ecosystem started moving towards es6 modules I've found it frustrating at times trying to search through randomly ordered import statements. Recently I've been sorting imports manually when I've added new code or touched old code so I thought I'd add an ESLint rule to codify it.
no issue
- review use of Ember core hooks and add a call to `this._super` if missing
- fix a few occurrences of using the wrong component lifecycle hooks that could result in multiple/duplicate event handlers being attached
`_super` should always be called when overriding Ember's base hooks so that core functionality or app functionality added through extensions, mixins or addons is not lost. This is important as it guards against issues arising from later refactorings or core changes.
As example of lost functionality, there were a number of routes that extended from `AuthenticatedRoute` but then overrode the `beforeModel` hook without calling `_super` which meant that the route was no longer treated as authenticated.
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.
