v0.14.1
-
Fix
imports
inpackage.json
(#1807)This release contains a fix for the rarely-used
imports
feature inpackage.json
files that lets a package specify a custom remapping for import paths inside that package that start with#
. Support forimports
was added in version 0.13.9. However, the field was being incorrectly interpreted as relative to the importing file instead of to thepackage.json
file, which caused an import failure when the importing file is in a subdirectory instead of being at the top level of the package. Import paths should now be interpreted as relative to the correct directory which should fix these path resolution failures. -
Isolate implicit sibling scope lookup for
enum
andnamespace
The previous release implemented sibling namespaces in TypeScript, which introduces a new kind of scope lookup that doesn't exist in JavaScript. Exported members inside an
enum
ornamespace
block can be implicitly referenced in a siblingenum
ornamespace
block just by using the name without using a property reference. However, this behavior appears to only work forenum
-to-enum
andnamespace
-to-namespace
interactions. Even though sibling enums and namespaces with the same name can be merged together into the same underlying object, this implicit reference behavior doesn't work forenum
-to-namespace
interactions and attempting to do this with anamespace
-to-enum
interaction causes the TypeScript compiler itself to crash. Here is an example of how the TypeScript compiler behaves in each case:// "b" is accessible enum a { b = 1 } enum a { c = b } // "e" is accessible namespace d { export let e = 1 } namespace d { export let f = e } // "h" is inaccessible enum g { h = 1 } namespace g { export let i = h } // This causes the TypeScript compiler to crash namespace j { export let k = 1 } enum j { l = k }
This release changes the implicit sibling scope lookup behavior to only work for
enum
-to-enum
andnamespace
-to-namespace
interactions. These implicit references no longer work withenum
-to-namespace
andnamespace
-to-enum
interactions, which should more accurately match the behavior of the TypeScript compiler. -
Add semicolon insertion before TypeScript-specific definite assignment assertion modifier (#1810)
TypeScript lets you add a
!
after a variable declaration to bypass TypeScript's definite assignment analysis:let x!: number[]; initialize(); x.push(4); function initialize() { x = [0, 1, 2, 3]; }
This
!
is called a definite assignment assertion and tells TypeScript to assume that the variable has been initialized somehow. However, JavaScript's automatic semicolon insertion rules should be able to insert a semicolon before it:let a !function(){}()
Previously the above code was incorrectly considered a syntax error in TypeScript. With this release, this code is now parsed correctly.
-
Log output to stderr has been overhauled
This release changes the way log messages are formatted to stderr. The changes make the kind of message (e.g. error vs. warning vs. note) more obvious, and they also give more room for paragraph-style notes that can provide more detail about the message. Here's an example:
Before:
> example.tsx:14:25: warning: Comparison with -0 using the "===" operator will also match 0 14 │ case 1: return x === -0 ╵ ~~ > example.tsx:21:23: error: Could not resolve "path" (use "--platform=node" when building for node) 21 │ const path = require('path') ╵ ~~~~~~
After:
▲ [WARNING] Comparison with -0 using the "===" operator will also match 0 example.tsx:14:25: 14 │ case 1: return x === -0 ╵ ~~ Floating-point equality is defined such that 0 and -0 are equal, so "x === -0" returns true for both 0 and -0. You need to use "Object.is(x, -0)" instead to test for -0. ✘ [ERROR] Could not resolve "path" example.tsx:21:23: 21 │ const path = require('path') ╵ ~~~~~~ The package "path" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "--platform=node" to do that, which will remove this error.
Note that esbuild's formatted log output is for humans, not for machines. If you need to output a stable machine-readable format, you should be using the API for that. Build and transform results have arrays called
errors
andwarnings
with objects that represent the log messages. -
Show inlined enum value names in comments
When esbuild inlines an enum, it will now put a comment next to it with the original enum name:
// Original code const enum Foo { FOO } console.log(Foo.FOO) // Old output console.log(0); // New output console.log(0 /* FOO */);
This matches the behavior of the TypeScript compiler, and should help with debugging. These comments are not generated if minification is enabled.