Treat NoSubstitutionTemplateLiteral same as a StringLiteral in import statement #29318
Description
TypeScript Version: 3.2
Search Terms: NoSubstitutionTemplateLiteral, import template literal
Code
import * as ts from `typescript`Expected behavior:
No error, as the NoSubstitutionTemplateLiteral should be treated just as a StringLiteral. Or potentially cannot find module error, depending on whether the module is installed.
Actual behavior:
Throws the error: "String literal expected"
Playground Link:
playground link
Related Issues:
This idea was touched on by #17704, but I guess this use case slipped through the cracks.
Activity
ericbf commentedon Jan 9, 2019
Andy (Andrewkraft) (@Andy-MS) Ron Buckton (@rbuckton) you guys were involved in that other PR. Thoughts here?
DanielRosenwasser commentedon Jan 9, 2019
The ECMAScript grammar currently only permits double- and single-quoted string literals in module specifiers:
https://tc39.github.io/ecma262/#prod-ImportDeclaration
https://tc39.github.io/ecma262/#prod-ModuleSpecifier
https://tc39.github.io/ecma262/#prod-StringLiteral
ericbf commentedon Jan 9, 2019
This would be very useful for teams that opt to use template strings only rather than mixing quote marks (see template literals are strictly better strings for some reasoning).
I'll log a request with ECMA to add their
NoSubstitutionLiterals to theirStringLiteraldefinition, but for the meantime, this change can safely be done in TS.By safely, I mean that no matter their decision, it won't introduce breaking changes in the future to realign the grammars. If they decide to incorporate the suggestion, then TS is already up to date and can remain as is (possibly translating
NoSubstitutionTemplateLiterals in imports to standard strings). If they reject it, then TS has another benefit that "vanilla" ECMA does not.TS treats its
NoSubstitutionTemplateLiterals the same asStringLiterals elsewhere. From my research, this may be the remaining use case preventing teams from exclusively using template strings.I'd implore you to explore this as something actually worth doing, rather than dismissing it solely on the fact that ECMA currently does not allow their equivalent token to be used this way.
ericbf commentedon Jan 9, 2019
Created #1399 on the ECMA page.