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 enable and enable-line directives that name an ignored rule. Such rules are switched on at the error level, 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_this will 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_length over a bare disable, which also hides problems you did not intend to accept.
  • Keep regions short. Always pair a disable with an enable, 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-line for 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