/cc @rwjblue

We discussed that we can catch accessibility issues and more in this addon. Introducing David Peter, @sarenji, from the Ember A11y team. 😄 Amusingly, the ember-a11y addon came out of the same Zesty Hack Day as ember-cli-template-lint.

• {{action}} on non-default-interactive elements (https://github.com/rwjblue/ember-template-lint/issues/41).
• img elements without an alt= specified (https://github.com/rwjblue/ember-template-lint/issues/45).
• ???

Linter should allow us to disable triple-curlies.

Hi, not sure if this is on purpose but I'm getting no warnings when I test my build with this template:

<div>
<div>
{{#if isSingleError}}
{{firstError}}
{{else if errors}}
{{errors}}
{{else}}
{{t 'no errors found'}}
{{/if}}
</div>
</div>

Should warn about multiple incorrect indentation correct?

I'm testing with ember serve and visiting: http://localhost:4200/tests

May be related to #36

Hi, @rwjblue first of all, thank you so much for all the stuff you do for Ember, awesome work!
I just tried this since it seems like an awesome idea but I'm having trouble seeing the linter output.
Is this supposed to happen?

1. update cli to 2.4.2 and install [email protected]
2. ember serve
3. see multiple linter warnings
4. don't fix anything
5. restart ember serve
6. no errors show up (although they are still there)

I even rm -rf tmp/ dist/ and start the server again but nothing shows up. I know the errors are still there because I didn't fix them.
How can I re-lint my files?

Thank you so much in advance!

<div>
    <h1>{{translate 'heading'}}</h1>
</div>

For the above snippet, it throws the error
Incorrect indentation for <h1> beginning at ('app/pods/application/template.hbs'@ L2:C1). Expected <h1> to be at an indentation of 2 but was found at 1.

Even if the above snippet is changed as the following, it throws the same error

<div>
    <h1>
        {{translate 'heading'}}
    </h1>
</div>

In the lintFor function, is there anyway that this returns a list of templates that failed?

{{#if isMorning}}
  Good morning
{{else if isAfternoon}}
  Good afternoon
{{else}}
  Good night
{{/if}}

Will report:

Incorrect indentation for `if` beginning at ('rwe/components/criteria-operator-select/template.hbs'@ L3:C0).
Expected `{{/if}}` ending at ('rwe/components/criteria-operator-select/template.hbs'@ L7:C0)to be at an indentation of 0 but was found at -7.

Something that plagues our templates is inconsistent quotes. For example, take the following snippets:

{{edit-person name="Jessica Jones" changed=(action 'personChanged')}}

<div class="messages">
  {{#each messages as |message|}}
    <span class='message'>{{message}}</span>
  {{/each}}
</div>

Similar to the rules used in ember-suave, it would be great to enforce a consistent quote style across an app.

I personally prefer using double quotes in html/templates, but I think consistency is the most important. This should probably be configurable in order to migrate existing projects easier.

Some examples of what I'd be fine with:

{{edit-person name="Jessica Jones" changed=(action "personChanged")}}

<div class="messages">
  {{#each messages as |message|}}
    <span class="message">{{message}}</span>
  {{/each}}
</div>

{{! single quotes are okay, if they contain double quotes }}
{{edit-person name='Zebediah "Purple man" Killgrave' changed=(action "personChanged")}}

The error message should contain the exact position of the 'wrong' string, so fixing the error is easy and editor integration is not broken.

Currently, our rules are all enabled by default, but I think that could likely get annoying as we add more rules.

I think that we should likely migrate to all rules needing to be enabled in the .template-lintrc file. We can make this easier by adding a blueprint that generates one with nice defaults (currently, it would just enable all rules 😝).

Thoughts?

Sometimes we require symbols such as : , ( , ) , + , - ,etc., to be displayed in the web page. For that we can go for using bare strings instead of translating for each symbols.
For eg:
{{translate "firstname.label"}} : {{input type="text"}}
{{translate "requestGradePoint"}} : {{input type="number"}} / {{input type="number"}}
<p>&times;</p> for 'x'

Things like:

<img alt="lolol, you do not know english">

A few obvious ones:

• placeholder
• alt
• title

What other attributes are troublesome?

We should add a generic mechanism to check each element attribute. Something like isAttributeBareStringAllowed(tagName, attributeName, value) should do the trick.

Per-template rules don't seem to work correctly in some cases. With the following config:

module.exports = {
  'bare-strings': true,
  'triple-curlies': true
};

and the following template:

<!-- template-lint triple-curlies=false -->
<div>Bare strings are bad...</div>
{{{tripleCurliesAreAllowedInThisTemplate}}}

I'm seeing a Usage of triple curly brackets is unsafe '{{{tripleCurliesAreAllowedInThisTemplate}}}' error.

Is also see the error if I use the following template:

<!-- template-lint disable=true -->
<div>Bare strings are bad...</div>
{{{tripleCurliesAreAllowedInThisTemplate}}}

{{#x-foo}}bar{{/x-foo}}

will report

Incorrect indentation for `x-foo` beginning at ('template.hbs'@ L1:C0). 
Expected `{{/x-foo}}` ending at ('template.hbs'@ L1:C14) to be at an indentation of 0 but was found at 14.

Which is incorrect IMO.

I've used ember install ember-cli-template-lint and modified .template-lintrc to look like this:

module.exports = {
    rules: {
        'self-closing-void-elements': true,
    }
};

When I use ember template-lint:print-failing I get a nice list of all templates in my app that break the rule. No addon files are inspected.

When I use ember test or ember build I get:

self-closing-void-elements: Self-closing a void element is redundant(modules/ember-cli-head/templates/components/head-layout):
`<meta name="ember-cli-head-start" />`
self-closing-void-elements: Self-closing a void element is redundant(modules/ember-cli-head/templates/components/head-layout @ L1:C52):
`<meta name="ember-cli-head-end" />`
===== 2 Template Linting Errors

Which ignored in-app templates and instead linted the ones from ember-cli-head addon.

I've tried to debug it and found that lintTree(type, tree) hook in https://github.com/rwjblue/ember-cli-template-lint/blob/master/index.js#L18 is called only twice and for this specific addon with type === 'addon' and type === 'templates.
After digging in ember-cli I've found that lintTree is only mentioned in the addon context:

• https://github.com/ember-cli/ember-cli/blob/master/lib/broccoli/ember-app.js#L566
• https://github.com/ember-cli/ember-cli/blob/master/lib/models/addon.js#L735

Does it mean that ember-cli-template-lint is designed for addons only? I don't see any info about this and it doesn't really make sense given that ember template-lint:print-failing lints the app templates.
Did I misconfigure something? You can check my setup at https://github.com/Wikia/mercury/tree/ember-cli-template-lint/front/main

Hi, would you mind adding a change log file? Maybe an automated one from your commits or latest pull requests would suffice. This is moving so fast it's hard to follow : )

Thanks!

This could be tricky because you need to know the context a template is operating in, and probably all helpers/components, but if I have the following in a template:

{{foo}} and {{bar}}

And the following component:

export default Component.extend({
  foo: "here"
});

It should warn that bar is not defined.

Add rule name, description, and reasoning to the README....

I am working this weekend to split the rules from ember-cli-template-lint into ember-template-lint which has a simple JS API (and is unrelated to ember-cli). This library would then consume that external lib, and work exactly the same as it does today.

This will unlock a number of things:

• Writing the reverse of sourceForNode (ala rewriteNode or something).
• Add a command line invocation (outside of ember-cli land)
• Use both of those things and add a --fix command to rewrite mechanical refactors (aka {{each foo in bar}} to {{each bar as |foo|}}). This could be used like (or from) ember-watson.

Hey @rwjblue just tried your last release v0.2.9 that enforces indentation. Awesome job!
Everything seems fine except for a minor message error. See below:

I have this incorrectly indented template:

{{#each groupedServices as |group|}}
  <li>{{group.groupName}}
    <ul>
      {{#each group.services as |service|}}
        <li>{{service.name}}</li>
      {{/each}}
    </ul>
  </li>
{{/each}}

And I get an error warning me about the {{group.groupName}} that is in the wrong place:

Incorrect indentation for `{{#group.groupName}}` beginning at ('code/templates/components/services.hbs'@ L2:C6). Expected `{{#group.groupName}}` to be at an indentation of 4 but was found at 6.

The bug here is that the error says I should look for a {{#group.groupName}}where in fact I should be looking for {{{{group.groupName}}}}i.e. without the #.

One again thanks for your awesome work!

With block-indentation, the following throws an error:

<div>
  {{t 'Use the following ID:'}}
  {{t 'id-prefix-'}}{{id}}
</div>

However, in some cases this can be necessary, e.g. if you do not want to have whitespace between two elements or translated strings. I feel that non-block handlebars expressions should not be required to be in their own lines.

it seems BasePlugin#sourceForNode() trims first character of AttrNodes.
from log i made:

----
{ type: 'AttrNode',
  name: 'src',
  value: { type: 'TextNode', chars: 'tomster.png', loc: null },
  loc:
   { source: null,
     start: { line: 1, column: 20 },
     end: { line: 1, column: 36 } } }
===
rc='tomster.png'
===

This change breaks the block indentation rule because now this check passes for text nodes. This is because this:

{{#if foo}}
  {{foo}}
{{/if}}

is a MustacheStatement whose first child is a TextNode containing the two spaces before the {{foo}}. Those two spaces' location points to column 0, which the block indentation logic flags as incorrect, and then when trying to log the error, throws an exception on this line because text nodes don't have a path attribute.

I think the fix is to look for an explicit list of node types instead of the !child.loc check, but I don't have time to prepare a fix right now. If somebody else does, great, otherwise maybe we can just pin the version of htmlbars to 0.14.16 until we have time to get in a fix?

<h1>Foo</h1>


<ul>
  <li>something</li>
  <li>interesting</li>
</ul>

Should warn about an extra white line on line 3.

One of my dependency addon in package.json contains errors in templates.

I want to get warnings message for the template inside this particular folder instead of getting huge errors errors.

Please find the below example

Example:

my-addon (I using ember-cli-template-lint in my addon only)
   |
   | node_modules
              |
              | internal-addons => (which is throwing a lot of template related errors, 
I want this addon shouldn't validate or to throw warning 
message instead of error )

I have used below, but this not working properly

'use strict';

module.exports = {
  extends: 'recommended',

  rules: {
    'bare-strings': false,
    'img-alt-attributes': true,
    'self-closing-void-elements': true,
    'invalid-interactive': true
  },

  pending: [
    'modules/internal-addons/component/**'
  ]
};

Help on this please.

Im most projects, we recommend that using css to style the dom elements. But some ones may prefer to write inline style rules, because it's just quick! I would be wonderful if we have a rule that totally disallow inline style rules. And it would be even more wonderful if we can add inline directive comment to disable a rule for some rare reasons.

The README doesn't describe when linting occurs. It would be helpful information to include and what kind of error to expect/see.

Straightforward enough- a rule (or pair of rules) defining which types of quotation marks (' vs. ") are allowed in templates.

Hey, maybe my indentation is weird here but I think no error should show up for this:

<input
  type="text"
  value={{if extra.labelPath (get selected extra.labelPath) selected}}
  class="ember-power-select-typeahead-input"
  oninput={{action "search" value="target.value"}}
  onkeydown={{action "onkeydown"}}
  onmousedown={{action "onmousedown"}}>

But I'm getting the following error:

Incorrect indentation for `input` beginning at ('code/templates/components/input-trigger.hbs'@ L1:C0). Expected `</input>` ending at ('code/templates/components/input-trigger.hbs'@ L7:C44)to be at an indentation of 0 but was found at 36.

If i put the input closing >char on the next line at position 0 I get indentation of 0 but was found at -7. which is weird, no?

No error is thrown if I put the whole input in a single line. Or like this:

<input
  type="text"
  value={{if extra.labelPath (get selected extra.labelPath) selected}}
  class="ember-power-select-typeahead-input"
  oninput={{action "search" value="target.value"}}
  onkeydown={{action "handleKeydown"}}
  onmousedown={{action "captureMouseDown"}}
       >

I understand why this is happening, but should an error be thrown here? If yes, maybe the expectation of the closing ">" char position should be different.

Thanks a lot in advance!

This requires updates to ember-cli itself to ensure lintTree('template' is called (we should also probably add lintTree('style' too).

Given the following:

{{#foo-bar as |blah|}}
  Stuff goes here, but doesn't use block param at all.
{{/foo-bar}}

We should error indicating that the block param was not used (roughly the same as an unused variable in JS linters).

As of #27 we are no longer using ember-template-compiler.js, so we can now support deprecations across a number of Ember versions.

A few things that jump out are:

• {{#each foo in bar}}{{/each}} #84
• {{#each foo itemController="asdf" as |bar}}{{/each}}
• {{#view 'foo'}}{{/view}}
• {{view 'foo'}}
• {{view.some.path}}
• {{input on="enter" action="lol"}}

There are likely more...

I can't think of a good use case for using <!-- HTML comments --> in templates since {{!-- handlebars comments --}} serve the purpose of commenting the template, but are not included in the compiled output and eventual DOM. But I'm so used to HTML comments that I always forget and use them when I don't mean to! I'd love a lint rule to catch this.

I see that the linter uses HTML comments for its instructions. Is this because brocolli-template-lint doesn't expose handlebars comments or something? Or could it instead support instructions in handlebars comments? I believe this rule could be made to work either way (obviously ignoring HTML comments that are instructions to the linter).

I'd be happy to take a crack at a PR for this if it sounds like a good idea outside of my head as well as inside of it 😄

This would allow a project to begin using ember-cli-template-lint ensuring new templates match the rules chosen in the projects .template-lintrc.js file, and allow them to slowing remove the disable comments from each file as they are touched/fixed.

Should allow ignoring a specific rule or all rules (ala // jscs disable)...

Dynamic lookups in partials quickly become untenable because they have absolutely no limitations to the things they can reach out and "get". It also becomes nearly impossible to refactor the template/controller/component invoking the partial without completely internalizing absolutely everything since they have no established API.

Good:

{{! some-path/-blah.hbs }}
{{! no dynamic lookups here}}
<svg></svg>

Bad:

{{! some-path/-blah.hbs }}
{{! oh no dynamic lookups here!! }}
<div>{{foo}}</div>

Since textareas are block elements, the linter will instruct the closing tag to match the indentation of the opening tag.

e.g. to change

<textarea></textarea>

to

<textarea>
</textarea>

When this rule is obeyed the textarea will include the added whitespace in the input box.

This took a while to debug :-)

Heres the rule message:

block-indentation: Incorrect indentation for `textarea` beginning at L31:C6. Expected `</textarea>` ending at L36:C88 to be at an indentation of 6 but was found at 77.(live-ops/templates/components/new-last-minute-job-form @ L36:C88): 

`<textarea class="form-control"
                id="job-instructions"
                rows="3"
                placeholder="Do it well"
                value={{job.instructions}}
                oninput={{action 'updateInstructions' value='target.value'}}></textarea>`

Any ideas for a potential fix? In the mean time I'll disable the rule.

This is a rule that @mixonic and @rwjblue suggested.

Basically https://github.com/rwjblue/ember-cli-template-lint/blob/97b78516f7af459a0da67d42223d6caa432abfcc/index.js#L10-L58 should be moved into https://github.com/mixonic/ember-cli-deprecation-workflow (they are not linting related unless we say deprecations are linting failures)....

This would likely fall into the block-indentation rule, but the basic idea is that for HTML elements that span multiple lines you want to ensure they start and stop at the same location.

<!-- bad -->

<div>
  <p>SomeStuff Here</p></div>

<!-- good -->

<div>
  <p>SomeStuff Here</p>
</div>

<div><p>SomeStuff Here</p></div>

Following on from https://github.com/rwjblue/ember-cli-template-lint/pull/68, I'd like to add some acceptance tests to verify the actual output of templates in the DOM, especially with per-template configuration.

I need to research the reason why further, but it seems that the lintTree hook in index.js isn't called for the templates tree when running the dummy app. It's only called for app and tests.

TODO:

• Upgrade to ember-cli latest

Sister to ember-cli/ember-cli-eslint#92

Running the linting without running the whole test suite may be beneficial. Returning an error code for failures may help for CIs. I'm not familiar with this codebase, but if it functions like eslint, you may be able to get faster results if you don't have to wait for a complete ember build.

Currently the name of a test looks like this:

TemplateLint - path/to/template.hbs: should pass TemplateLint

To define better testing stages for CI/CD pipelines it would be great to have the possibility to configure the name to get something like this:

TemplateLint - Unit - path/to/template.hbs: should pass TemplateLint

In my templates, I have a few things like this:

({{t 'Optional'}})

Because I do not want to have both 'Optional' and '(Optional)' in my translation files. However, ( and ) are counted as untranslated strings. The same happens if I use numbers. I think it would make sense to only throw this error for strings containing letters, and ignore it if a string contains only numbers and/or special characters.

it's true that you can self close void elements and the DOMParser will ignore this, but it leads to a bad pattern that many coders treat HTML as it was XML.

and of course i can create a PR