Sourced from esbuild's releases.
v0.21.3
Implement the decorator metadata proposal (#3760)
This release implements the decorator metadata proposal, which is a sub-proposal of the decorators proposal. Microsoft shipped the decorators proposal in TypeScript 5.0 and the decorator metadata proposal in TypeScript 5.2, so it's important that esbuild also supports both of these features. Here's a quick example:
// Shim the "Symbol.metadata" symbol Symbol.metadata ??= Symbol('Symbol.metadata')const track = (_, context) => { (context.metadata.names ||= []).push(context.name) }
class Foo {
@trackfoo = 1@trackbar = 2 }// Prints ["foo", "bar"] console.log(Foo[Symbol.metadata].names)
⚠️ WARNING ⚠️
This proposal has been marked as "stage 3" which means "recommended for implementation". However, it's still a work in progress and isn't a part of JavaScript yet, so keep in mind that any code that uses JavaScript decorator metadata may need to be updated as the feature continues to evolve. If/when that happens, I will update esbuild's implementation to match the specification. I will not be supporting old versions of the specification.
Fix bundled decorators in derived classes (#3768)
In certain cases, bundling code that uses decorators in a derived class with a class body that references its own class name could previously generate code that crashes at run-time due to an incorrect variable name. This problem has been fixed. Here is an example of code that was compiled incorrectly before this fix:
class Foo extends Object { @(x => x) foo() { return Foo } } console.log(new Foo().foo())Fix
tsconfig.jsonfiles inside symlinked directories (#3767)This release fixes an issue with a scenario involving a
tsconfig.jsonfile thatextendsanother file from within a symlinked directory that uses thepathsfeature. In that case, the implicitbaseURLvalue should be based on the real path (i.e. after expanding all symbolic links) instead of the original path. This was already done for other files that esbuild resolves but was not yet done fortsconfig.jsonbecause it's special-cased (the regular path resolver can't be used because the information insidetsconfig.jsonis involved in path resolution). Note that this fix no longer applies if the--preserve-symlinkssetting is enabled.v0.21.2
Correct
thisin field and accessor decorators (#3761)This release changes the value of
thisin initializers for class field and accessor decorators from the module-levelthisvalue to the appropriatethisvalue for the decorated element (either the class or the instance). It was previously incorrect due to lack of test coverage. Here's an example of a decorator that doesn't work without this change:const dec = () => function() { this.bar = true }
... (truncated)
Sourced from esbuild's changelog.
0.21.3
Implement the decorator metadata proposal (#3760)
This release implements the decorator metadata proposal, which is a sub-proposal of the decorators proposal. Microsoft shipped the decorators proposal in TypeScript 5.0 and the decorator metadata proposal in TypeScript 5.2, so it's important that esbuild also supports both of these features. Here's a quick example:
// Shim the "Symbol.metadata" symbol Symbol.metadata ??= Symbol('Symbol.metadata')const track = (_, context) => { (context.metadata.names ||= []).push(context.name) }
class Foo {
@trackfoo = 1@trackbar = 2 }// Prints ["foo", "bar"] console.log(Foo[Symbol.metadata].names)
⚠️ WARNING ⚠️
This proposal has been marked as "stage 3" which means "recommended for implementation". However, it's still a work in progress and isn't a part of JavaScript yet, so keep in mind that any code that uses JavaScript decorator metadata may need to be updated as the feature continues to evolve. If/when that happens, I will update esbuild's implementation to match the specification. I will not be supporting old versions of the specification.
Fix bundled decorators in derived classes (#3768)
In certain cases, bundling code that uses decorators in a derived class with a class body that references its own class name could previously generate code that crashes at run-time due to an incorrect variable name. This problem has been fixed. Here is an example of code that was compiled incorrectly before this fix:
class Foo extends Object { @(x => x) foo() { return Foo } } console.log(new Foo().foo())Fix
tsconfig.jsonfiles inside symlinked directories (#3767)This release fixes an issue with a scenario involving a
tsconfig.jsonfile thatextendsanother file from within a symlinked directory that uses thepathsfeature. In that case, the implicitbaseURLvalue should be based on the real path (i.e. after expanding all symbolic links) instead of the original path. This was already done for other files that esbuild resolves but was not yet done fortsconfig.jsonbecause it's special-cased (the regular path resolver can't be used because the information insidetsconfig.jsonis involved in path resolution). Note that this fix no longer applies if the--preserve-symlinkssetting is enabled.0.21.2
Correct
thisin field and accessor decorators (#3761)This release changes the value of
thisin initializers for class field and accessor decorators from the module-levelthisvalue to the appropriatethisvalue for the decorated element (either the class or the instance). It was previously incorrect due to lack of test coverage. Here's an example of a decorator that doesn't work without this change:
... (truncated)
efa3dd2
publish 0.21.3 to npm5e7cf25
fix #3760:
implement decorator metadata proposalbd0b13b
lowering: always propagate class expression names90acd14
explicit bitwise operators for initializer flagsba548df
move decorator initializer list to after the class66b7c6d
fix #3768:
bundled decorators in derived classes6e6f15f
fix #3767:
tsconfig.json files inside symlinksb7dcb95
transform: reuse lowerField for auto-accessorsb24180e
publish 0.21.2 to npmf82e0ad
fix #3761:
this in field and accessor decorators