Lints

Author: NullVoxPopuli

README.md

@@ -473,6 +473,8 @@ rules in templates can be disabled with eslint directives with mustache or html
 | [order-in-models](docs/rules/order-in-models.md)                             | enforce proper order of properties in models                   |    | 🔧 |    |
 | [order-in-routes](docs/rules/order-in-routes.md)                             | enforce proper order of properties in routes                   |    | 🔧 |    |
 | [template-attribute-order](docs/rules/template-attribute-order.md)           | enforce consistent ordering of attributes in template elements |    |    |    |
+| [template-eol-last](docs/rules/template-eol-last.md)                         | require or disallow newline at the end of template files       |    | 🔧 |    |
+| [template-linebreak-style](docs/rules/template-linebreak-style.md)           | enforce consistent linebreaks in templates                     |    | 🔧 |    |
 | [template-modifier-name-case](docs/rules/template-modifier-name-case.md)     | require dasherized names for modifiers                         |    | 🔧 |    |
 | [template-no-only-default-slot](docs/rules/template-no-only-default-slot.md) | disallow using only the default slot                           |    | 🔧 |    |
 | [template-quotes](docs/rules/template-quotes.md)                             | enforce consistent quote style in templates                    |    | 🔧 |    |

docs/rules/template-eol-last.md

@@ -0,0 +1,56 @@
+# ember/template-eol-last
+
+🔧 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+<!-- end auto-generated rule header -->
+
+Require or disallow newline at the end of template files.
+
+## Rule Details
+
+This rule enforces at least one newline (or no newline) at the end of template files.
+
+## Config
+
+This rule accepts a single string option:
+
+- `"always"` (default) — enforces that template files end with a newline
+- `"never"` — enforces that template files do not end with a newline
+
+## Examples
+
+Examples of **incorrect** code with the default `"always"` config:
+
+```hbs
+<div>test</div>
+```
+
+Examples of **correct** code with the default `"always"` config:
+
+```hbs
+<div>test</div>
+{{! newline at end of file }}
+```
+
+Examples of **incorrect** code with the `"never"` config:
+
+```hbs
+<div>test</div>
+{{! trailing newline not allowed }}
+```
+
+Examples of **correct** code with the `"never"` config:
+
+```hbs
+<div>test</div>
+```
+
+## Related Rules
+
+- [eol-last](https://eslint.org/docs/rules/eol-last) from eslint
+
+## References
+
+- [ember-template-lint eol-last](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/eol-last.md)
+- [POSIX standard/line](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206)
+- [Wikipedia/newline](https://en.wikipedia.org/wiki/Newline#Interpretation)

docs/rules/template-linebreak-style.md

@@ -0,0 +1,56 @@
+# ember/template-linebreak-style
+
+🔧 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+<!-- end auto-generated rule header -->
+
+Enforce consistent linebreaks in templates.
+
+Having consistent linebreaks is important to make sure that the source code is rendered correctly in editors.
+
+## Rule Details
+
+This rule enforces consistent line endings in templates, independent of the operating system.
+
+## Config
+
+This rule accepts a single string option:
+
+- `"unix"` (default) — enforces the usage of Unix line endings: `\n` for LF
+- `"windows"` — enforces the usage of Windows line endings: `\r\n` for CRLF
+- `"system"` — enforces the usage of the current platform's line ending
+
+## Examples
+
+Examples of **incorrect** code with the default `"unix"` config:
+
+```hbs
+<div>test</div>\r\n
+```
+
+Examples of **correct** code with the default `"unix"` config:
+
+```hbs
+<div>test</div>\n
+```
+
+Examples of **incorrect** code with the `"windows"` config:
+
+```hbs
+<div>test</div>\n
+```
+
+Examples of **correct** code with the `"windows"` config:
+
+```hbs
+<div>test</div>\r\n
+```
+
+## Related Rules
+
+- [linebreak-style](https://eslint.org/docs/rules/linebreak-style) from eslint
+
+## References
+
+- [ember-template-lint linebreak-style](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/linebreak-style.md)
+- [Git/line endings](https://docs.github.com/en/github/using-git/configuring-git-to-handle-line-endings)

docs/rules/template-no-action.md

@@ -6,12 +6,43 @@
 
 Disallows the use of `{{action}}` helper.
 
+"Action" is an overloaded term in Ember. Actions are methods on the `actions` hash, element modifiers that set up event handlers, partial-applied functions, and something we both pass downward and send back up. They have served many different purposes over the years, which makes them difficult to learn, teach, and repurpose.
+
+```hbs
+<button {{action 'increment' 5}}>Click</button>
+<button {{action this.increment 5}}>Click</button>
+<button onclick={{action 'increment' 5}}>Click</button>
+<button onclick={{action this.increment 5}}>Click</button>
+<button {{action (action 'increment' 5)}}>Click</button>
+<button {{action (action this.increment 5)}}>Click</button>
+```
+
 The `{{action}}` helper is deprecated in favor of the `{{on}}` modifier and `{{fn}}` helper, which provide better performance and clearer intent.
 
 ## Examples
 
 Examples of **incorrect** code for this rule:
 
+```hbs
+<button onclick={{action 'foo'}}></button>
+```
+
+```hbs
+<button {{action 'submit'}}>Submit</button>
+```
+
+```hbs
+<FooBar @baz={{action 'submit'}} />
+```
+
+```hbs
+{{yield (action 'foo')}}
+```
+
+```hbs
+{{yield (action this.foo)}}
+```
+
 ```hbs
 <button {{on 'click' (action 'save')}}>Save</button>
 ```
@@ -22,6 +53,14 @@ Examples of **incorrect** code for this rule:
 
 Examples of **correct** code for this rule:
 
+```hbs
+<button {{on 'submit' @action}}>Click Me</button>
+```
+
+```hbs
+<button {{on 'submit' this.action}}>Click Me</button>
+```
+
 ```hbs
 <button {{on 'click' this.save}}>Save</button>
 ```
@@ -36,8 +75,33 @@ Examples of **correct** code for this rule:
 
 ## Migration
 
-- Replace `(action "methodName")` with method references or `(fn this.methodName)`
-- Replace `<button onclick={{action ...}}>` with `<button {{on "click" ...}}>`
+```hbs
+<select onchange={{action this.updateSelection this.options}}>
+  {{#each this.options as |opt|}}
+    <option>{{opt.value}}</option>
+  {{/each}}
+</select>
+```
+
+to
+
+```hbs
+<select {{on 'change' (fn this.updateSelection this.options)}}>
+  {{#each this.options as |opt|}}
+    <option>{{opt.value}}</option>
+  {{/each}}
+</select>
+```
+
+```hbs
+<MyComponent @onValidationChange={{action 'onDateValidation'}} />
+```
+
+to
+
+```hbs
+<MyComponent @onValidationChange={{this.onDateValidation}} />
+```
 
 ## Related Rules
 
@@ -47,6 +111,8 @@ Examples of **correct** code for this rule:
 
 ## References
 
-- [eslint-plugin-ember template-no-action](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/template-no-action.md)
+- [Ember Octane Update: What's up with `@action`?](https://www.pzuraq.com/blog/ember-octane-update-action/)
+- [RFC-471 `on` modifier](https://github.com/emberjs/rfcs/blob/master/text/0471-on-modifier.md)
+- [RFC-470 `fn` helper](https://github.com/emberjs/rfcs/blob/master/text/0470-fn-helper.md)
 - [Ember.js Deprecations - action helper](https://deprecations.emberjs.com/v3.x/#toc_action-helper)
 - [Ember Modifier Documentation](https://guides.emberjs.com/release/components/template-lifecycle-dom-and-modifiers/)

docs/rules/template-no-implicit-this.md

@@ -6,9 +6,7 @@
 
 Require explicit `this` for property access in templates to avoid ambiguity.
 
-## Rule Details
-
-This rule requires explicitly using `this.` prefix for component properties and `@` prefix for named arguments in templates, avoiding ambiguous property references.
+This rule aides in the migration path for [emberjs/rfcs#308](https://github.com/emberjs/rfcs/pull/308).
 
 ## Motivation
 
@@ -21,6 +19,78 @@ ambiguous, as it could be referring to a local variable (block param), a helper
 with no arguments, a closed over component, or a property on the component
 class.
 
+Consider the following example where the ambiguity can cause issues:
+
+You have a component class that looks like the following component and template:
+
+```js
+import Component from '@ember/component';
+import computed from '@ember/computed';
+
+export default Component.extend({
+  formatName: computed('firstName', 'lastName', function () {
+    return `${this.firstName} ${this.lastName}`;
+  }),
+});
+```
+
+```hbs
+<h1>Hello {{formatName}}!</h1>
+```
+
+Given `{ firstName: 'Chad', lastName: 'Hietala' }`, Ember will render the
+following:
+
+```html
+<h1>Hello Chad Hietala!</h1>
+```
+
+Now some time goes on and someone adds a `formatName` helper at
+`app/helpers/formatName.js` that looks like the following:
+
+```js
+export default function formatName([firstName, lastName]) {
+  return `${firstName} ${lastName}`;
+}
+```
+
+Due to the fact that helpers take precedence over property lookups, our
+`{{formatName}}` now resolves to a helper. When the helper runs it doesn't have
+any arguments so our template now renders the following:
+
+```html
+<h1>Hello !</h1>
+```
+
+This can be a refactoring hazard and can often lead to confusion for readers of
+the template. Upon encountering `{{greeting}}` in a component's template, the
+reader has to check all of these places: first, you need to scan the
+surrounding lines for block params with that name; next, you check in the
+helpers folder to see if there is a helper with that name (it could also be
+coming from an addon!); finally, you check the component's JavaScript class to
+look for a (computed) property.
+
+Like
+[RFC#0276](https://github.com/emberjs/rfcs/blob/master/text/0276-named-args.md)
+made argument usage explicit through the `@` prefix, the `this` prefix will
+resolve the ambiguity and greatly improve clarity, especially in big projects
+with a lot of files (and uses a lot of addons).
+
+As an aside, the ambiguity that causes confusion for human readers is also a
+problem for the compiler. While it is not the main goal of this proposal,
+resolving this ambiguity also helps the rendering system. Currently, the
+"runtime" template compiler has to perform a helper lookup for every
+`{{greeting}}` in each template. It will be able to skip this resolution
+process and perform other optimizations (such as reusing the internal
+[reference](https://github.com/glimmerjs/glimmer-vm/blob/master/guides/04-references.md)
+object and caches) with this addition.
+
+Furthermore, by enforcing the `this` prefix, tooling like the [Ember Language
+Server](https://github.com/emberwatch/ember-language-server) does not need to
+know about fallback resolution rules. This makes common features like ["Go To
+Definition"](https://code.visualstudio.com/docs/editor/editingevolved#_go-to-definition)
+much easier to implement since we have semantics that mean "property on class".
+
 ## Examples
 
 Examples of **incorrect** code for this rule:
@@ -47,5 +117,7 @@ Examples of **correct** code for this rule:
 
 ## References
 
+- [Glimmer components](https://guides.emberjs.com/release/upgrading/current-edition/glimmer-components/)
+- [RFC#0276 - Named Args](https://github.com/emberjs/rfcs/blob/master/text/0276-named-args.md#motivation)
+- [RFC#308 - Deprecate implicit this](https://github.com/emberjs/rfcs/blob/master/text/0308-deprecate-property-lookup-fallback.md)
 - [Ember Octane Guide - Templates](https://guides.emberjs.com/release/components/component-state-and-actions/)
-- [RFC #308 - Deprecate implicit this](https://github.com/emberjs/rfcs/blob/master/text/0308-deprecate-property-lookup-fallback.md)