Template literals are unsupported for nested calls

[ExE-Boss]

The following is unsupported despite it being allowed by the type system:

chalk.bold`Hello, {cyan.inverse ${name}!} This is a test. {green ${exclamation}!}`;

Produces:

Hello, {cyan.inverse ,!} This is a test. {green ,!} Sindre Neat

Instead of:

Hello, Sindre! This is a test. Neat!

---

IssueHunt Summary

toonijn has been rewarded.

Backers (Total: $40.00)

• issuehunt ($40.00)

Submitted pull Requests

• #392 Support for template literals for nested calls
• #398 Support nested calls

---

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[i-break-codes]

Just came to say this, I can't do the following, for example:

function test(message) {
  console.log(chalk`
    ${message}
  `);
}
test('There are {bold 5280 feet} in a mile. In {bold miles}, there are {green.bold feet}.')

Outputs as There are {bold 5280 feet} in a mile. In {bold miles}, there are {green.bold feet}.

Any solution to the above?

[Qix-]

@i-break-codes The OP is an entirely different issue. What you want is specifically not supported. You'll need to write a template literal wrapper, as template literals are not as simple as a function call.

@ExE-Boss's issue is that the typescript definitions allow you to use chalk.bold or chalk.someotherstyle as the base for a tagged template literal, which we also do not support.

[sindresorhus]

So what needs to be done here is to change the TypeScript types to not allow the template literal on Chalk sub-properties like chalk.bold, correct?

[Qix-]

Correct. Only on instances of Chalk directly.

[issuehunt-oss]

@issuehunt has funded $40.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[ExE-Boss]

I feel like fixing the TypeScript definition is not worth 40 bucks.

I’d much rather prefer if this was implemented so that:

chalk.red`foo ${bar}`;

and

chalk`{red foo ${bar}}`;

were equivalent.

That way, bugs like mdn/browser-compat-data#4480 could be more easily avoided.

[sindresorhus]

I agree, would be better to actually support that.

[Qix-]

Supporting that is going to introduce more branching to the individual styles in order to check to see if the passed arguments match that of a tagged template invocation (since there's no quick way to check).

I really wish the folks at the tc39 thought about this; the design is horrendous. I really wish they had created a specified function property that was invoked instead, so you'd have

function foo() {
    console.log('regular invocation');
}

foo.tag = function() {
    console.log('tagged invocation');
}

foo(); // regular invocation
foo`hello`; // tagged invocation

But alas, we have to check the existence of random properties and arrays which take the form of if statements.

Supporting this will ultimately hurt performance by introducing branching. Is that what we want?

[sindresorhus]

Let's fix the TypeScript definition for now, and we can look into allowing it later on, as long as the performance is not impacted (which seems hard).

[jsejcksn]

as long as the performance is not impacted

Maybe the performance tradeoff will be worth it? Are there perf tests to inform a decision?

[toonijn]

I proposed a solution in #392 . The behavior of

has not changed, so there is backwards compatibility without performance hit.

Only when the functions is called as a template literal, the template substitution will be evaluated:

Note the difference between chalk.bold(`... and chalk.bold`...

[Qix-]

without performance hit

You cannot possibly assert this. There is no special function invocation for template literals aside from different argument types, so you'd have to do a branch (an if statement) in order to determine if you're being called as a literal.

Branches are very much overhead, and can be quite detrimental in tight loops if gone unchecked.

[issuehunt-oss]

@sindresorhus has rewarded $36.00 to @toonijn. See it on IssueHunt

• 💰 Total deposit: $40.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $4.00