Add test for TemplateStrings caching

[jridgewell]

Safari 12 has a bug that breaks caching of TemplateStrings.

Test case: https://jsbin.com/leyusas/10/edit?js,console

Unfortunately, it's a memory GC bug, so it's very difficult to write a test that would catch this.

Re: babel/babel#9584

[ljharb]

LGTM but maybe we could add a note to the test linking to the bug, and explaining why the test might be tricky to verify?

[jridgewell]

Done.

[zloirock]

Please, rebuild it one more time.

[jridgewell]

Done.

[moderndeveloperllc]

@jridgewell Just come upon this when updating to the babel 7.4 (which includes the compat-table build that fixes this). One of the things this fix means is that any build that targets 'last 2 Safari major versions', via browserlist syntax is now including the babelHelpers.taggedTemplateLiteral() where previously it was not. This can cause build pipeline issues with projects using a module/nomodule split as this is not normally needed for ES6 module-compatible browsers.

What did this bug cause to happen? Before I go and refudge my config, I was hoping to figure out if I really need to serve Safari 12 the helper-wrapped version or not. Thanks.

[jridgewell]

The bug causes:

function strings(array) {
  return array;
}
function getStrings() {
  return strings`foo`;
}

const ref = getStrings();

// This should always be true
// It may not be in Safari
ref === getStrings();

Many libraries use the "always the same reference" property to do caching (via WeakMaps) of expensive work. If the references are not the same, then the caching is broken and the expensive work has to be redone. In some libraries, it can cause serious bugs.

[moderndeveloperllc]

@jridgewell Thanks for the explanation. It's unfortunate that babel preset-env currently can't handle the case of a feature having upper bounds in compat-table. BTW, you may want to add this issue to core-js as that is what babel is transitioning to it appears. There does not appear to be a template literals test in the list there.