restrict-template-expressions.md

description
Enforce template literal expressions to be of `string` type.

🛑 This file is source code, not the primary documentation location! 🛑

See https://typescript-eslint.io/rules/restrict-template-expressions for documentation.

JavaScript automatically converts an object to a string in a string context, such as when concatenating it with a string using + or embedding it in a template literal using ${}. The default toString() method of objects returns "[object Object]", which is often not what was intended. This rule reports on values used in a template literal string that aren't strings, numbers, or BigInts, optionally allowing other data types that provide useful stringification results.

:::note

The default settings of this rule intentionally do not allow objects with a custom toString() method to be used in template literals, because the stringification result may not be user-friendly.

For example, arrays have a custom toString() method, which only calls join() internally, which joins the array elements with commas. This means that (1) array elements are not necessarily stringified to useful results (2) the commas don't have spaces after them, making the result not user-friendly. The best way to format arrays is to use Intl.ListFormat, which even supports adding the "and" conjunction where necessary. You must explicitly call object.toString() if you want to use this object in a template literal, or turn on the allowArray option to specifically allow arrays. The no-base-to-string rule can be used to guard this case against producing "[object Object]" by accident.

:::

Examples

❌ Incorrect

const arg1 = [1, 2];
const msg1 = `arg1 = ${arg1}`;

const arg2 = { name: 'Foo' };
const msg2 = `arg2 = ${arg2 || null}`;

✅ Correct

const arg = 'foo';
const msg1 = `arg = ${arg}`;
const msg2 = `arg = ${arg || 'default'}`;

const stringWithKindProp: string & { _kind?: 'MyString' } = 'foo';
const msg3 = `stringWithKindProp = ${stringWithKindProp}`;

Options

allowNumber

Examples of additional correct code for this rule with { allowNumber: true }:

const arg = 123;
const msg1 = `arg = ${arg}`;
const msg2 = `arg = ${arg || 'zero'}`;

This option controls both numbers and BigInts.

allowBoolean

Examples of additional correct code for this rule with { allowBoolean: true }:

const arg = true;
const msg1 = `arg = ${arg}`;
const msg2 = `arg = ${arg || 'not truthy'}`;

allowAny

Examples of additional correct code for this rule with { allowAny: true }:

const user = JSON.parse('{ "name": "foo" }');
const msg1 = `arg = ${user.name}`;
const msg2 = `arg = ${user.name || 'the user with no name'}`;

allowNullish

Examples of additional correct code for this rule with { allowNullish: true }:

const arg = condition ? 'ok' : null;
const msg1 = `arg = ${arg}`;

allowRegExp

Examples of additional correct code for this rule with { allowRegExp: true }:

const arg = new RegExp('foo');
const msg1 = `arg = ${arg}`;

const arg = /foo/;
const msg1 = `arg = ${arg}`;

allowNever

Examples of additional correct code for this rule with { allowNever: true }:

const arg = 'something';
const msg1 = typeof arg === 'string' ? arg : `arg = ${arg}`;

allowArray

Examples of additional correct code for this rule with { allowArray: true }:

const arg = ['foo', 'bar'];
const msg1 = `arg = ${arg}`;

When Not To Use It

If you're not worried about incorrectly stringifying non-string values in template literals, then you likely don't need this rule.

Related To

• no-base-to-string
• restrict-plus-operands