Tagged template literals compiled incorrectly, TemplateStringsArray not cached

[justinfagnani]

TypeScript Version: 2.4.1

Code

let previousStrings;

function test(strings, ...value) {
  if (previousStrings !== undefined && previousStrings !== strings) {
    window.alert('failure');
  }
  previousStrings = strings;
}

function go(n) {
  return test`literal ${n}`;
}

Expected behavior:

According to the ECMAScript spec, every time a template tag is evaluated, the same strings object should be passed as the first argument:

Each TemplateLiteral in the program code of a realm is associated with a unique template object that is used in the evaluation of tagged Templates (12.2.9.6). The template objects are frozen and the same template object is used each time a specific tagged Template is evaluated.

https://tc39.github.io/ecma262/#sec-gettemplateobject

Actual behavior:

The above snippet compiles to:

var previousStrings;
function test(strings) {
    var value = [];
    for (var _i = 1; _i < arguments.length; _i++) {
        value[_i - 1] = arguments[_i];
    }
    if (previousStrings !== undefined && previousStrings !== strings) {
        window.alert('failure');
    }
    previousStrings = strings;
}
function go(n) {
    return (_a = ["literal ", ""], _a.raw = ["literal ", ""], test(_a, n));
    var _a;
}

You can see that _a is going to have a new identity for each call of go().

FWIW, Babel compiles this correctly:

'use strict';

var _templateObject = _taggedTemplateLiteral(['literal ', ''], ['literal ', '']);

function _taggedTemplateLiteral(strings, raw) { return Object.freeze(Object.defineProperties(strings, { raw: { value: Object.freeze(raw) } })); }

var previousStrings = void 0;

function test(strings) {
  if (previousStrings !== undefined && previousStrings !== strings) {
    window.alert('failure');
  }
  previousStrings = strings;
}

function go(n) {
  return test(_templateObject, n);
}

This is breaking lit-html when used in TypeScript: lit/lit#58

[PatrickJS]

Is there a workaround for typescript to do this correctly or do we have to wait for a patch? For future facing JavaScript frameworks moving away from virtual-dom (hyperHTML, lit-html) this is a bit of a problem (trying to avoid memory leaks)

[DanielRosenwasser]

For now I'd rather wait on the most recent discussions (https://github.com/rwaldron/tc39-notes/blob/master/es8/2017-07/jul-27.md and tc39/ecma262#840) to get settled out first before we revisit the implementation.

Specifically, it's not clear whether the following behavior will hold:

function id(x) { return x }

id `` === id `` // true

[justinfagnani]

@DanielRosenwasser whether or not equal literals from separate source locations remain identical might be up in the air, but this should be true:

let t = () => id``;

t() === t(); // true

That it isn't is a pretty critical bug that prevents using TemplateStringsArray as map key. Until this is fixed I need to tell my TypeScript users to target esnext, then compile with Babel.

The incremental fix is to hoist the TemplateStringsArray declaration to the top-level:

var _a = ["literal ", ""];
_a.raw = ["literal ", ""];

function go(n) {
    return test(_a, n);
}

[PatrickJS]

for anyone using template literals for example hyperHTML, vyperHTML, or lit-html you can use this feature detection

const shouldCacheTemplates = ((_t) => _t() === _t())(() => ((s: any) => s)``);
const cacheTemplates = new Map<string, TemplateStringsArray>();


function tagged(strings: TemplateStringsArray, ...values: any[]) {
  if (shouldCacheTemplates) {
    let key = strings.join('{{typescriptProblems}}');
    let _strings = cacheTemplates.get(key)
    if (_strings === undefined) {
      cacheTemplates.set(key, strings)
    } else {
      strings = _strings
    }
  }

}

[PatrickJS]

do you think a typescript plugin could be used as a workaround?
https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

[justinfagnani]

@gdi2290 A plugin would need to change its behavior depending on the target. When the target is es2015+, there's no bug. Only when the target is <= ES5 is there a problem. That may be possible though, I haven't written a plugin yet.

[WebReflection]

@DanielRosenwasser is there an ETA for this bug to be fixed?

If not, is there a way from JS side to feature-detect TypeScript env is running?

I already fallback for old versions of FireFox that were incompatible with ES2015 standard, but being template literals feature-undetectable I need to use some ugly hack to know it's TypeScript and fallback with the solution I know it works already (per realm).

Thanks in advance for any advice.

[DanielRosenwasser]

@WebReflection Technically you can check whether the raw property is enumerable. TypeScript's is enumerable, whereas the one in ES2015 runtimes should be non-enumerable. But I hesitate from recommending you take a dependency on that since we still intend on supporting the feature in ES3 runtimes.

I already have a prototype working. We're thinking about 2.6, but are concerned with trying to do the more standards-compliant thing but still coming short with respect to having globally cached template literal objects.

[WebReflection]

Thanks @DanielRosenwasser, but it's still undetectable to me, unless I put that check (even once) in the entry point of my logic.

It's a great hint, but it's too specific. What I really would like to know, is if there's any (hidden?) global/scoped TypeScript leak I can detect upfront, like a typeof _classCreator === 'function' within my code, in case it gets "compiled" with TypeScript projects.