no-unused-expressions and template literals (`)

Looks like template literals with custom interpolators with no brackets are not treated by eslint as proper function calls. The following example produces an error:

import injectGlobal from 'styled-components';

// OK (with brackets)
injectGlobal(`
  body {
    color: #000,
  }
`);

// causes eslint error (no brackets)
injectGlobal`
  body {
    background: #f00,
  }
`;

11:1  error  Expected an assignment or function call and instead saw an expression  no-unused-expressions

• ESLint Version: 3.10.2
• Node Version: 6.9.1
• npm Version: 3.10.8

What parser (default, Babel-ESLint, etc.) are you using? babel-eslint 7.1.1

Please show your full configuration:

  "eslintConfig": {
    "parser": "babel-eslint",
    "plugins": [
      "import"
    ],
    "rules": {
      "no-unused-expressions": 2
    }
  }

What did you do? Please include the actual source code causing the issue.

MWE: https://github.com/kachkaev/eslint-no-unused-expressions

git clone [e-mail]:kachkaev/eslint-no-unused-expressions.git
npm install
npm run lint:eslint

What did you expect to happen?

I expected both injectGlobal( and injectGlobal not to produce any eslint errors as these are just normal function calls; they are identical to each other.

[platinumazure]

Working on this now.

[not-an-aardvark]

👍 for adding allowTemplateTags: true.

👎 for adding allowTemplateTags: ["foo", "bar"]

My gut impression is that adding an option like allowTemplateTags: ["injectGlobal"] might be excessive. It would have to use the static name for the tag, so it wouldn’t work if the function was renamed within the code. It would also fail for cases like this:

/* eslint no-unused-expressions: [error, {"allowTemplateTags": ["injectGlobal", "injectLocal"]}] */

(foo ? injectGlobal : injectLocal)`
  body {
    color: red;
  }
` // incorrectly reports an error

var foo = {inject: injectGlobal};

foo.inject`
  body {
    color: red;
  }
` // incorrectly reports an error

We don’t have an option like allowTernary: ["foo", "bar"], presumably for similar reasons. I think the small utility provided by allowing an array isn’t worth having the rule incorrectly report errors in more complicated scenarios.