This is an edge case, but my team for various reasons decided to use template literals everywhere instead of strings. In almost all cases this seems to not have any drawbacks, except this case I'm reporting and one other edge case I may report separately. Maybe we shouldn't be using template literals in this spot, but the transpilation should probably not crash regardless. In our scenario emitDecoratorMetadata is required (for TypeORM) and that option is required to reproduce the bug.
TypeScript Version:
3.8.3
typescript@next 4.0.0-dev.20200508
Search Terms:
decorator
quotes
backtick
Code
import "reflect-metadata";
const formatMetadataKey = Symbol("format");
function format(formatString: string) {
return Reflect.metadata(formatMetadataKey, formatString);
}
function getFormat(target: any, propertyKey: string) {
return Reflect.getMetadata(formatMetadataKey, target, propertyKey);
}
class Greeter {
@format("Hello, %s")
greeting: `boss` | `employee` = `employee`; //template literals on this line cause the issue
constructor(message: 'boss' | 'employee') {
this.greeting = message;
}
greet() {
const formatString = getFormat(this, "greeting");
return formatString.replace("%s", this.greeting);
}
}
const g = new Greeter('boss')
g.greet()Expected behavior:
Compiles normally.
Actual behavior:
Throws exception:
/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:81040
throw e;
^
Error: Debug Failure. Unexpected node.
Node 14 was unexpected.
at serializeTypeNode (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64342:45)
at serializeTypeList (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64391:44)
at serializeTypeNode (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64356:28)
at serializeTypeOfNode (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64249:28)
at addOldTypeMetadata (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64191:92)
at addTypeMetadata (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64185:17)
at transformAllDecoratorsOfDeclaration (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64104:13)
at generateClassElementDecorationExpression (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64129:40)
at generateClassElementDecorationExpressions (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64115:34)
at addClassElementDecorationStatements (/Users/jcullison/.config/yarn/global/node_modules/typescript/lib/tsc.js:64108:44)
Playground Link: Provided
Console output:
Error: Debug Failure. Unexpected node.
Node NoSubstitutionTemplateLiteral was unexpected.
Related Issues:
(similar idea) #37276
Example cli:*
tsc --outdir ./build --target ES2019 --experimentalDecorators -emitDecoratorMetadata ./test-param-decorator.ts
This is an edge case, but my team for various reasons decided to use template literals everywhere instead of strings. In almost all cases this seems to not have any drawbacks, except this case I'm reporting and one other edge case I may report separately. Maybe we shouldn't be using template literals in this spot, but the transpilation should probably not crash regardless. In our scenario
emitDecoratorMetadatais required (for TypeORM) and that option is required to reproduce the bug.TypeScript Version:
3.8.3
typescript@next 4.0.0-dev.20200508
Search Terms:
decorator
quotes
backtick
Code
Expected behavior:
Compiles normally.
Actual behavior:
Throws exception:
Playground Link: Provided
Console output:
Error: Debug Failure. Unexpected node.
Node NoSubstitutionTemplateLiteral was unexpected.
Related Issues:
(similar idea) #37276
Example cli:*
tsc --outdir ./build --target ES2019 --experimentalDecorators -emitDecoratorMetadata ./test-param-decorator.ts