Inline Directives
Inline directives are special comments that switch rules off or on for part of a file. They let you keep a strict project-wide configuration while handling justified exceptions exactly where they occur, with the reason visible to reviewers.
Directive Syntax
A directive is the text coffeelint: followed by a command and an optional comma-separated list of rule names:
# coffeelint: disable=max_line_length
# coffeelint: enable=max_line_length
# coffeelint: disable-line=no_trailing_semicolons
# coffeelint: enable-line=no_implicit_parens
# coffeelint: disable
# coffeelint: enable
| Command | Scope | Effect |
|---|---|---|
disable=rules |
From this line onward | Suppresses the listed rules until a matching enable. |
enable=rules |
From this line onward | Re-activates the listed rules. |
disable-line=rules |
This line only | Suppresses the listed rules on the directive's own line. |
enable-line=rules |
This line only | Activates the listed rules on the directive's own line. |
disable (no list) |
From this line onward | Suppresses all rules. |
enable (no list) |
From this line onward | Restores the state defined by your configuration. |
disable-line (no list) |
This line only | Suppresses all rules on this line. |
Rule lists may contain spaces after commas: # coffeelint: disable=no_tabs, max_line_length.
Disabling a Block
Wrap the code that legitimately breaks a rule:
# coffeelint: disable=max_line_length
object:
attr: "some/huge/line/string/with/embed/#{values}.that/surpasses/the/max/column/width"
# coffeelint: enable=max_line_length
Everything between the two directives is exempt from max_line_length; every other rule still applies.
You can disable several rules at once and re-enable everything with a bare enable:
# coffeelint: disable=no_trailing_semicolons,no_implicit_parens
a 'you get a semi-colon';
b 'you get a semi-colon';
# coffeelint: enable
c 'everybody gets a semi-colon';
With both rules active in the configuration, only line 5 is reported (once for each rule), because the bare enable restores the configured state.
Disabling a Single Line
Put a disable-line directive at the end of the offending line:
a 'foo'; # coffeelint: disable-line=no_trailing_semicolons
b 'bar';
Only line 2 is reported. Without a rule list, disable-line silences every rule on that line:
a 'foo'; # coffeelint: disable-line
The noqa Shortcut
Any line containing a # followed later by the text noqa is treated as # coffeelint: disable-line. This is convenient if you already use the noqa convention from other linters:
a 'foo'; # noqa
Because the match is a simple pattern (# followed by noqa anywhere later on the line), avoid the word noqa in ordinary comments on lines you want linted.
Enabling Rules That Your Configuration Ignores
Directives can also turn on a rule that is set to ignore, for one region of a file:
# coffeelint: enable=no_implicit_parens
a 'implicit parens here'
b 'implicit parens', 'also here'
# coffeelint: disable=no_implicit_parens
c 'implicit parens allowed here'
With the default configuration (where no_implicit_parens is ignored), lines 2 and 3 are reported and line 5 is not. A single line works too:
a 'foo'
b 'bar' # coffeelint: enable-line=no_implicit_parens
c 'baz'
Only line 2 is reported.
How this works, and its limits:
- Before linting, CoffeeLint scans the file for
enableandenable-linedirectives that name an ignored rule. Such rules are switched on at theerrorlevel, whatever their usual default, and kept suppressed until the directive line is reached. - This pre-scan only recognizes a directive that names exactly one rule.
# coffeelint: enable=no_plusplus,no_thiswill not turn on two ignored rules; write one directive per rule instead.
Interaction with Syntax Errors
If a file contains a CoffeeScript syntax error, CoffeeLint reports the coffeescript_error and skips the token and line passes. Inline directives are collected during the line pass, so they have no effect on such a file. Fix the syntax error first.
Best Practices
- Be specific. Prefer
disable=max_line_lengthover a baredisable, which also hides problems you did not intend to accept. - Keep regions short. Always pair a
disablewith anenable, and keep the exempt region as small as possible. Otherwise the rule stays off until the end of the file. - Explain why. Add a short comment above the directive so reviewers understand the exception.
- Prefer
disable-linefor one-liners. It cannot accidentally leak to the rest of the file. - Use configuration for systematic exceptions. If you disable the same rule in many files, change the level in Configuration instead.
See Also
- Rules Overview for the names of all rules.
- Architecture for where directive processing happens in the linting pipeline.