You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expected behavior:
After compiling and running the code in a browser console, the body's content should be "true".
The code works as expected when compiled with Babel, or run verbatim in a browser console.
Actual behavior:
The body's content becomes "false". This breaks libraries such as hyperHTML (note: now it contains a workaround that works for me at least WebReflection/hyperHTML@6d3d879)
The problem here is that we do the right thing in modules, but not in the global scope because we don't want to have potentially conflicting variables. So we could just come up with absurdly long variable names that describe the string contents and work with that.
Close to 2 years, and still no fixes, but people keep filing issues to my libraries: ungap/template-literal#10
My workaround is also mostly reliable, but it's based on "signing" each template literal, assuming two templates literals with the same content comes from the same scope/callback.
This plays well until you have people doing, for a reason or another, the following:
All three empty template literals produces the same template signature, so there's no way to reasonably cache and assign a unique identifier to each of them.
This issue is easily breaking in the wild otherwise perfectly valid code, and as there's no workaround to solve this in user-land, except telling people to not use TypeScript to transpile, I hope it'll get a higher priority.
The current measure I'm considering in here, is to remove any normalization, which will penalize TypeScript users performances as there will be tons of unnecessary DOM trashes in code transpiled in the wild, including CodePens, code in any html page, etc etc.
Best Regards.
Reacted by luigi, Владимир, yuretz, Emanuele Stoppa, Alexandre Oger, Aurelio, William Linna and Garnet
This doesn't seem like an important scenario for modern JS development - folks can either target ES6 which is supported basically everywhere, or use an alternate transpiler with stricter adherence semantics if this is important for their scenario.
Ryan Cavanaugh (@RyanCavanaugh) my last comment was from 4 years ago ... sure thing I wouldn't care about this today but thanks for reminding me this never got fixed or received any attention it deserved, in the name of transpiling to Web standards, to date.
Yet I agree nobody should care about this anymore these days, thanks!
Activity
DanielRosenwasser commentedon Oct 1, 2018
The problem here is that we do the right thing in modules, but not in the global scope because we don't want to have potentially conflicting variables. So we could just come up with absurdly long variable names that describe the string contents and work with that.
WebReflection commentedon Jun 14, 2020
Close to 2 years, and still no fixes, but people keep filing issues to my libraries:
ungap/template-literal#10
My workaround is also mostly reliable, but it's based on "signing" each template literal, assuming two templates literals with the same content comes from the same scope/callback.
This plays well until you have people doing, for a reason or another, the following:
All three empty template literals produces the same template signature, so there's no way to reasonably cache and assign a unique identifier to each of them.
A better playground has been created:
https://bit.ly/2XYvAmY
it's based on the following code:
This issue is easily breaking in the wild otherwise perfectly valid code, and as there's no workaround to solve this in user-land, except telling people to not use TypeScript to transpile, I hope it'll get a higher priority.
The current measure I'm considering in here, is to remove any normalization, which will penalize TypeScript users performances as there will be tons of unnecessary DOM trashes in code transpiled in the wild, including CodePens, code in any html page, etc etc.
Best Regards.
RyanCavanaugh commentedon Feb 23, 2024
This doesn't seem like an important scenario for modern JS development - folks can either target ES6 which is supported basically everywhere, or use an alternate transpiler with stricter adherence semantics if this is important for their scenario.
WebReflection commentedon Feb 23, 2024
Ryan Cavanaugh (@RyanCavanaugh) my last comment was from 4 years ago ... sure thing I wouldn't care about this today but thanks for reminding me this never got fixed or received any attention it deserved, in the name of transpiling to Web standards, to date.
Yet I agree nobody should care about this anymore these days, thanks!