esbuild 0.12.16

v0.12.16

on Node.js NPM

Remove warning about bad CSS @-rules (#1426)

The CSS bundler built in to esbuild is only designed with real CSS in mind. Running other languages that compile down to CSS through esbuild without compiling them down to CSS first can be a bad idea since esbuild applies browser-style error recovery to invalid syntax and uses browser-style import order that other languages might not be expecting. This is why esbuild previously generated warnings when it encountered unknown CSS @-rules.

However, some people want to run other non-CSS languages through esbuild's CSS bundler anyway. So with this release, esbuild will no longer generate any warnings if you do this. But keep in mind that doing this is still potentially unsafe. Depending on the input language, using esbuild's CSS bundler to bundle non-CSS code can still potentially alter the semantics of your code.

Allow ES2021 in tsconfig.json (#1470)

TypeScript recently added support for ES2021 in tsconfig.json so esbuild now supports this too. This has the same effect as if you passed --target=es2021 to esbuild. Keep in mind that the value of target in tsconfig.json is only respected if you did not pass a --target= value to esbuild.

Avoid using the worker_threads optimization in certain old node versions (#1462)

The worker_threads optimization makes esbuild's synchronous API calls go much faster than they would otherwise. However, it turns out this optimization cannot be used in certain node versions older than v12.17.0, where node throws an error when trying to create the worker. This optimization is now disabled in these scenarios.

Note that these old node versions are currently in maintenance. I recommend upgrading to a modern version of node if run-time performance is important to you.

Paths starting with node: are implicitly external when bundling for node (#1466)

This replicates a new node feature where you can prefix an import path with node: to load a native node module by that name (such as import fs from "node:fs/promises"). These paths also have special behavior:

Core modules can also be identified using the node: prefix, in which case it bypasses the require cache. For instance, require('node:http') will always return the built in HTTP module, even if there is require.cache entry by that name.

With this release, esbuild's built-in resolver will now automatically consider all import paths starting with node: as external. This new behavior is only active when the current platform is set to node such as with --platform=node. If you need to customize this behavior, you can write a plugin to intercept these paths and treat them differently.

Consider \ and / to be the same in file paths (#1459)

On Windows, there are many different file paths that can refer to the same underlying file. Windows uses a case-insensitive file system so for example foo.js and Foo.js are the same file. When bundling, esbuild needs to treat both of these paths as the same to avoid incorrectly bundling the file twice. This is case is already handled by identifying files by their lower-case file path.

The case that wasn't being handled is the fact that Windows supports two different path separators, / and \, both of which mean the same thing. For example foo/bar.js and foo\bar.js are the same file. With this release, this case is also handled by esbuild. Files that are imported in multiple places with inconsistent path separators will now be considered the same file instead of bundling the file multiple times.