Looking at #9009 there are a lot of great changes

• replacing ember-cli-eslint with plain old eslint
• running commands in parallel
• a nice convention of lint:* and test:* npm scripts

Great work all round 🎉

I looked at adopting this approach in our projects. We're not using travis for CI, so that's one difference.. but we do run npm test (technically yarn test) in CI, which

I'm looking for a convention/standard to document components, especially targeting these information:

• arguments
• attributes
• yield

for components, template-only components while supporting for java- and typescript. Primarily focused for glimmer components, yet the js-only approach should also be suitable to be applied to ember components, too.

The idea is, that these conventions can

Document the set of plugins, config and setup used to deploy to fastboot. This should be on the website, perhaps in a Recipes section.

It would be extremely valuable, given that we have migrated the docs to utilize gh-pages and they are versioned, that we could merge those into this repo so that we could public apidocs as well.

Thoughts?

Update docs to recommend the usage of ember-cli-dependency-lint to prevent errors like #445.

We get regular questions about how to deal with not having allowed values on the this of the TestContext (e.g. here). We should document an example of how to set up the test context!

When using the menu to create a "js only" component, this is the full content of the js file:

export default 

@Gaurav0 mentioned that the relevant code can be found at https://github.com/ember-cli/ember-twiddle/blob/e7e6732cfad7c0fb41238fb17141b455c966ff72/app/mixins/files.js#L123-L129.

Currently in the docs there is a section for "Components" which is confusing when someone may be looking for how to test @ember/components in their application. It think it would make sense to rename this section to fragments or maybe "organizing and sharing functionality".

The emphasis for this is because with the addition of #444 and documentation around it would add official docs for how

The mocha tests are not being ran, so we are missing test coverage for mocha.

The tests in tests/unit/mocha/*-test.js are not executed, since its only running tests against qunit.

It doesn't appear that this plugin respects utils in the same way that it respects other elements of EmberJS.

My app/utils/ classes are hard to find using CMD-O class search. In addition to that, I cannot quick-navigate (CMD-SHIFT-T) back and forth between a util class and its test. I'm sure there are other symptoms of utility classes not working as expected; those are the two I bump

should be

ember build --environment production && ember github-pages:commit --message \"Deploy gh-pages from commit $(git rev-parse HEAD)\" && git push origin gh-pages:gh-pages

instead

Take the following example from the ec-addon-docs Quickstart guide:

{{#docs-viewer as |viewer|}}
  {{#viewer.nav as |nav|}}
    {{nav.item "Introduction" "docs.index"}}
  {{/viewer.nav}}

  {{#viewer.main}}
    {{outlet}}
  {{/viewer.main}}
{{/docs-viewer}}

The linter will spit out the following error:

Currently ember-cli-mocha just uses the HTML reporter that comes with mocha. While it works very well, it is difficult to extend and does not offer the same features as the QUnit output does. I came across @ef4's better-mocha-html-reporter which implemented an analogous reporter in ES6 and also cleaned up the styling.

I've since [extended it

Likely due to this bug: https://connect.microsoft.com/IE/feedback/details/792880/document-readystat

We need to check for readyState !== 'interactive' as well in the ready method for script-loader.js

  var ready = function (fn) {
    if (document.readyState !== 'loading' && document.readyState !== 'interactive') {
      fn();
    } else if (document.addEventListener) {
      docu

If a the testGenerator option is not set we should not set the group option to true.

It took me a while to figure out how to specify which form inputs to use. I had to look at the source to figure it out, so thought it'd be good to mention here. And maybe there is a better way.

In your own component or route, something like this to specify the selectors that match your inputs:

    this.set('formSelectors', {
      numberInput: "#ccNumPretty",
      nameInput: "#fullNa