evanw/esbuild v0.15.4 on GitHub

Consider TypeScript import assignments to be side-effect free (#2468)
TypeScript has a legacy import syntax for working with TypeScript namespaces that looks like this:
```
import { someNamespace } from './some-file'
import bar = someNamespace.foo;

// some-file.ts
export namespace someNamespace {
  export let foo = 123
}
```
Since esbuild converts TypeScript into JavaScript one file at a time, it doesn't know if bar is supposed to be a value or a type (or both, which TypeScript actually allows in this case). This is problematic because values are supposed to be kept during the conversion but types are supposed to be removed during the conversion. Currently esbuild keeps bar in the output, which is done because someNamespace.foo is a property access and property accesses run code that could potentially have a side effect (although there is no side effect in this case).
With this release, esbuild will now consider someNamespace.foo to have no side effects. This means bar will now be removed when bundling and when tree shaking is enabled. Note that it will still not be removed when tree shaking is disabled. This is because in this mode, esbuild supports adding additional code to the end of the generated output that's in the same scope as the module. That code could potentially make use of bar, so it would be incorrect to remove it. If you want bar to be removed, you'll have to enable tree shaking (which tells esbuild that nothing else depends on the unexported top-level symbols in the generated output).
Change the order of the banner and the "use strict" directive (#2467)
Previously the top of the file contained the following things in order:
1. The hashbang comment (see below) from the source code, if present
2. The "use strict" directive from the source code, if present
3. The content of esbuild's banner API option, if specified
This was problematic for people that used the banner API option to insert the hashbang comment instead of using esbuild's hashbang comment preservation feature. So with this release, the order has now been changed to:
1. The hashbang comment (see below) from the source code, if present
2. The content of esbuild's banner API option, if specified
3. The "use strict" directive from the source code, if present
I'm considering this change to be a bug fix instead of a breaking change because esbuild's documentation states that the banner API option can be used to "insert an arbitrary string at the beginning of generated JavaScript files". While this isn't technically true because esbuild may still insert the original hashbang comment before the banner, it's at least more correct now because the banner will now come before the "use strict" directive.
For context: JavaScript files recently allowed using a hashbang comment, which starts with #! and which must start at the very first character of the file. It allows Unix systems to execute the file directly as a script without needing to prefix it by the node command. This comment typically has the value #!/usr/bin/env node. Hashbang comments will be a part of ES2023 when it's released next year.
Fix exports maps with Yarn PnP path resolution (#2473)
The Yarn PnP specification says that to resolve a package path, you first resolve it to the absolute path of a directory, and then you run node's module resolution algorithm on it. Previously esbuild followed this part of the specification. However, doing this means that exports in package.json is not respected because node's module resolution algorithm doesn't interpret exports for absolute paths. So with this release, esbuild will now use a modified algorithm that deviates from both specifications but that should hopefully behave more similar to what Yarn actually does: node's module resolution algorithm is run with the original import path but starting from the directory returned by Yarn PnP.