[](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---|---|---| | | | lockFileMaintenance | All locks refreshed | | | | | | [@types/node](https://togithub.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/node) ([source](https://togithub.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)) | devDependencies | patch | [`20.12.8` -> `20.12.11`](https://renovatebot.com/diffs/npm/@types%2fnode/20.12.8/20.12.11) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | | [esbuild](https://togithub.com/evanw/esbuild) | devDependencies | minor | [`^0.20.0` -> `^0.21.0`](https://renovatebot.com/diffs/npm/esbuild/0.20.2/0.21.1) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | [](https://docs.renovatebot.com/merge-confidence/) | 🔧 This Pull Request updates lock files to use the latest dependency versions. --- ### Release Notes <details> <summary>evanw/esbuild (esbuild)</summary> ### [`v0.21.1`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0211) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.21.0...v0.21.1) - Fix a regression with `--keep-names` ([#​3756](https://togithub.com/evanw/esbuild/issues/3756)) The previous release introduced a regression with the `--keep-names` setting and object literals with `get`/`set` accessor methods, in which case the generated code contained syntax errors. This release fixes the regression: ```js // Original code x = { get y() {} } // Output from version 0.21.0 (with --keep-names) x = { get y: /* @​__PURE__ */ __name(function() { }, "y") }; // Output from this version (with --keep-names) x = { get y() { } }; ``` ### [`v0.21.0`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0210) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.20.2...v0.21.0) This release doesn't contain any deliberately-breaking changes. However, it contains a very complex new feature and while all of esbuild's tests pass, I would not be surprised if an important edge case turns out to be broken. So I'm releasing this as a breaking change release to avoid causing any trouble. As usual, make sure to test your code when you upgrade. - Implement the JavaScript decorators proposal ([#​104](https://togithub.com/evanw/esbuild/issues/104)) With this release, esbuild now contains an implementation of the upcoming [JavaScript decorators proposal](https://togithub.com/tc39/proposal-decorators). This is the same feature that shipped in [TypeScript 5.0](https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#decorators) and has been highly-requested on esbuild's issue tracker. You can read more about them in that blog post and in this other (now slightly outdated) extensive blog post here: https://2ality.com/2022/10/javascript-decorators.html. Here's a quick example: ```js const log = (fn, context) => function() { console.log(`before ${context.name}`) const it = fn.apply(this, arguments) console.log(`after ${context.name}`) return it } class Foo { @​log static foo() { console.log('in foo') } } // Logs "before foo", "in foo", "after foo" Foo.foo() ``` Note that this feature is different than the existing "TypeScript experimental decorators" feature that esbuild already implements. It uses similar syntax but behaves very differently, and the two are not compatible (although it's sometimes possible to write decorators that work with both). TypeScript experimental decorators will still be supported by esbuild going forward as they have been around for a long time, are very widely used, and let you do certain things that are not possible with JavaScript decorators (such as decorating function parameters). By default esbuild will parse and transform JavaScript decorators, but you can tell esbuild to parse and transform TypeScript experimental decorators instead by setting `"experimentalDecorators": true` in your `tsconfig.json` file. Probably at least half of the work for this feature went into creating a test suite that exercises many of the proposal's edge cases: https://github.com/evanw/decorator-tests. It has given me a reasonable level of confidence that esbuild's initial implementation is acceptable. However, I don't have access to a significant sample of real code that uses JavaScript decorators. If you're currently using JavaScript decorators in a real code base, please try out esbuild's implementation and let me know if anything seems off. **⚠️ WARNING ⚠️** This proposal has been in the works for a very long time (work began around 10 years ago in 2014) and it is finally getting close to becoming part of the JavaScript language. 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 decorators may need to be updated as the feature continues to evolve. The decorators proposal is pretty close to its final form but it can and likely will undergo some small behavioral adjustments before it ends up becoming a part of the standard. If/when that happens, I will update esbuild's implementation to match the specification. I will not be supporting old versions of the specification. - Optimize the generated code for private methods Previously when lowering private methods for old browsers, esbuild would generate one `WeakSet` for each private method. This mirrors similar logic for generating one `WeakSet` for each private field. Using a separate `WeakMap` for private fields is necessary as their assignment can be observable: ```js let it class Bar { constructor() { it = this } } class Foo extends Bar { #x = 1 #y = null.foo static check() { console.log(#x in it, #y in it) } } try { new Foo } catch {} Foo.check() ``` This prints `true false` because this partially-initialized instance has `#x` but not `#y`. In other words, it's not true that all class instances will always have all of their private fields. However, the assignment of private methods to a class instance is not observable. In other words, it's true that all class instances will always have all of their private methods. This means esbuild can lower private methods into code where all methods share a single `WeakSet`, which is smaller, faster, and uses less memory. Other JavaScript processing tools such as the TypeScript compiler already make this optimization. Here's what this change looks like: ```js // Original code class Foo { #x() { return this.#x() } #y() { return this.#y() } #z() { return this.#z() } } // Old output (--supported:class-private-method=false) var _x, x_fn, _y, y_fn, _z, z_fn; class Foo { constructor() { __privateAdd(this, _x); __privateAdd(this, _y); __privateAdd(this, _z); } } _x = new WeakSet(); x_fn = function() { return __privateMethod(this, _x, x_fn).call(this); }; _y = new WeakSet(); y_fn = function() { return __privateMethod(this, _y, y_fn).call(this); }; _z = new WeakSet(); z_fn = function() { return __privateMethod(this, _z, z_fn).call(this); }; // New output (--supported:class-private-method=false) var _Foo_instances, x_fn, y_fn, z_fn; class Foo { constructor() { __privateAdd(this, _Foo_instances); } } _Foo_instances = new WeakSet(); x_fn = function() { return __privateMethod(this, _Foo_instances, x_fn).call(this); }; y_fn = function() { return __privateMethod(this, _Foo_instances, y_fn).call(this); }; z_fn = function() { return __privateMethod(this, _Foo_instances, z_fn).call(this); }; ``` - Fix an obscure bug with lowering class members with computed property keys When class members that use newer syntax features are transformed for older target environments, they sometimes need to be relocated. However, care must be taken to not reorder any side effects caused by computed property keys. For example, the following code must evaluate `a()` then `b()` then `c()`: ```js class Foo { [a()]() {} [b()]; static { c() } } ``` Previously esbuild did this by shifting the computed property key *forward* to the next spot in the evaluation order. Classes evaluate all computed keys first and then all static class elements, so if the last computed key needs to be shifted, esbuild previously inserted a static block at start of the class body, ensuring it came before all other static class elements: ```js var _a; class Foo { constructor() { __publicField(this, _a); } static { _a = b(); } [a()]() { } static { c(); } } ``` However, this could cause esbuild to accidentally generate a syntax error if the computed property key contains code that isn't allowed in a static block, such as an `await` expression. With this release, esbuild fixes this problem by shifting the computed property key *backward* to the previous spot in the evaluation order instead, which may push it into the `extends` clause or even before the class itself: ```js // Original code class Foo { [a()]() {} [await b()]; static { c() } } // Old output (with --supported:class-field=false) var _a; class Foo { constructor() { __publicField(this, _a); } static { _a = await b(); } [a()]() { } static { c(); } } // New output (with --supported:class-field=false) var _a, _b; class Foo { constructor() { __publicField(this, _a); } [(_b = a(), _a = await b(), _b)]() { } static { c(); } } ``` - Fix some `--keep-names` edge cases The [`NamedEvaluation` syntax-directed operation](https://tc39.es/ecma262/#sec-runtime-semantics-namedevaluation) in the JavaScript specification gives certain anonymous expressions a `name` property depending on where they are in the syntax tree. For example, the following initializers convey a `name` value: ```js var foo = function() {} var bar = class {} console.log(foo.name, bar.name) ``` When you enable esbuild's `--keep-names` setting, esbuild generates additional code to represent this `NamedEvaluation` operation so that the value of the `name` property persists even when the identifiers are renamed (e.g. due to minification). However, I recently learned that esbuild's implementation of `NamedEvaluation` is missing a few cases. Specifically esbuild was missing property definitions, class initializers, logical-assignment operators. These cases should now all be handled: ```js var obj = { foo: function() {} } class Foo0 { foo = function() {} } class Foo1 { static foo = function() {} } class Foo2 { accessor foo = function() {} } class Foo3 { static accessor foo = function() {} } foo ||= function() {} foo &&= function() {} foo ??= function() {} ``` </details> --- ### Configuration 📅 **Schedule**: Branch creation - "before 4am on monday" in timezone Asia/Shanghai, Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/oxc-project/oxc). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4zNTEuMiIsInVwZGF0ZWRJblZlciI6IjM3LjM1MS4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> |
||
|---|---|---|
| .cargo | ||
| .github | ||
| .vscode | ||
| crates | ||
| editors/vscode | ||
| fuzz | ||
| napi/parser | ||
| npm | ||
| tasks | ||
| wasm/parser | ||
| website | ||
| .git-blame-ignore-revs | ||
| .gitignore | ||
| .ignore | ||
| .rustfmt.toml | ||
| .taplo.toml | ||
| .typos.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| cliff.toml | ||
| CONTRIBUTING.md | ||
| deny.toml | ||
| justfile | ||
| LICENSE | ||
| MAINTENANCE.md | ||
| README.md | ||
| rust-toolchain.toml | ||
| THIRD-PARTY-LICENSE | ||
⚓ Oxc
The Oxidation Compiler is creating a collection of high-performance tools for JavaScript and TypeScript.
Oxc is building a parser, linter, formatter, transpiler, minifier, resolver ... all written in Rust.
🙋Who's using Oxc?
- Rolldown uses the oxc crate for parsing.
- Rspack, Rolldown, and Biome uses the oxc_resolver crate for module resolution.
⚡️ Linter Quick Start
The linter is ready to catch mistakes for you. It comes with 91 rules turned on by default (out of 300 in total) and no configuration is required.
To get started, run oxlint or via npx:
npx oxlint@latest
To give you an idea of its capabilities, here is an example from the vscode repository, which finishes linting 4800+ files in 0.7 seconds.
⚡️ Performance
- The parser aim to be the fastest Rust-based ready-for-production parser.
- The linter is more than 50 times faster than ESLint, and scales with the number of CPU cores.
⌨️ Programming Usage
Rust
Individual crates are published, you may use them to build your own JavaScript tools.
- The umbrella crate oxc exports all public crates from this repository.
- The AST and parser crates oxc_ast and oxc_parser are production ready.
- The resolver crate oxc_resolver for module resolution is also production ready.
- Example usages of these crates can be found in their respective
crates/*/examplesdirectory.
While Rust has gained a reputation for its comparatively slower compilation speed, we have dedicated significant effort to fine-tune the Rust compilation speed. Our aim is to minimize any impact on your development workflow, ensuring that developing your own Oxc based tools remains a smooth and efficient experience.
This is demonstrated by our CI runs, where warm runs complete in 3 minutes.
Node.js
- via napi: oxc-parser
Wasm
🎯 Tools
🔸 AST and Parser
Oxc maintains its own AST and parser, which is by far the fastest and most conformant JavaScript and TypeScript (including JSX and TSX) parser written in Rust.
As the parser often represents a key performance bottleneck in JavaScript tooling, any minor improvements can have a cascading effect on our downstream tools. By developing our parser, we have the opportunity to explore and implement well-researched performance techniques.
While many existing JavaScript tools rely on estree as their AST specification, a notable drawback is its abundance of ambiguous nodes. This ambiguity often leads to confusion during development with estree.
The Oxc AST differs slightly from the estree AST by removing ambiguous nodes and introducing distinct types.
For example, instead of using a generic estree Identifier,
the Oxc AST provides specific types such as BindingIdentifier, IdentifierReference, and IdentifierName.
This clear distinction greatly enhances the development experience by aligning more closely with the ECMAScript specification.
🏆 Parser Performance
Our benchmark reveals that the Oxc parser surpasses the speed of the swc parser by approximately 3 times and the Biome parser by 5 times.
How is it so fast?
- AST is allocated in a memory arena (bumpalo) for fast AST memory allocation and deallocation.
- Short strings are inlined by CompactString.
- No other heap allocations are done except the above two.
- Scope binding, symbol resolution and some syntax errors are not done in the parser, they are delegated to the semantic analyzer.
🔸 Linter
The linter embraces convention over configuration, eliminating the need for extensive configuration and plugin setup. Unlike other linters like ESLint, which often require intricate configurations and plugin installations (e.g. @typescript-eslint), our linter only requires a single command that you can immediately run on your codebase:
npx oxlint@latest
🏆 Linter Performance
The linter is 50 - 100 times faster than ESLint depending on the number of rules and number of CPU cores used. It completes in less than a second for most codebases with a few hundred files and completes in a few seconds for larger monorepos. See bench-javascript-linter for details.
As an upside, the binary is approximately 5MB, whereas ESLint and its associated plugin dependencies can easily exceed 100.
You may also download the linter binary from the latest release tag as a standalone binary, this lets you run the linter without a Node.js installation in your CI.
How is it so fast?
- Oxc parser is used.
- AST visit is a fast operation due to linear memory scan from the memory arena.
- Files are linted in a multi-threaded environment, so scales with the total number of CPU cores.
- Every single lint rule is tuned for performance.
🔸 Resolver
Module resolution plays a crucial role in JavaScript tooling, especially for tasks like multi-file analysis or bundling. However, it can often become a performance bottleneck. To address this, we developed oxc_resolver.
The resolver is production-ready and is currently being used in Rspack and Rolldown. Usage and examples can be found in its own repository.
🔸 Transformer (Transpiler)
A transformer is responsible for turning higher versions of ECMAScript to a lower version that can be used in older browsers. We are currently focusing on the architecture. See Milestone 1 for details.
🔸 Minifier
JavaScript minification plays a crucial role in optimizing website performance as it reduces the amount of data sent to users, resulting in faster page loads. This holds tremendous economic value, particularly for e-commerce websites, where every second can equate to millions of dollars.
However, existing minifiers typically require a trade-off between compression quality and speed. You have to choose between the slowest for the best compression or the fastest for less compression. But what if we could develop a faster minifier without compromising on compression?
We are actively working on a prototype that aims to achieve this goal, by porting all test cases from well-known minifiers such as google-closure-compiler, terser, esbuild, and tdewolff-minify.
Preliminary results indicate that we are on track to achieve our objectives. With the Oxc minifier, you can expect faster minification times without sacrificing compression quality.
🔸 Formatter
While prettier has established itself as the de facto code formatter for JavaScript, there is a significant demand in the developer community for a less opinionated alternative. Recognizing this need, our ambition is to undertake research and development to create a new JavaScript formatter that offers increased flexibility and customization options.
The prototype is currently work in progress.
✍️ Contribute
See CONTRIBUTING.md for guidance.
Check out some of the good first issues or ask us on Discord.
If you are unable to contribute by code, you can still participate by:
- Add a GitHub Star to the project.
- Join us on Discord.
- Follow me on twitter and tweet about this project.
📚 Learning Resources
- My small tutorial on how to write a JavaScript Parser in Rust
- My small article Pursuit of Performance on Building a JavaScript Compiler
- And more
🤝 Credits
This project was incubated with the assistance of these exceptional mentors and their projects:
- Biome - @ematipico
- Ruff - @charliermarsh, @MichaReiser
- quick-lint-js - @strager
- elm-review - @jfmengels
❤️ Sponsors
📖 License
Oxc is free and open-source software licensed under the MIT License.
Oxc ports or copies code from other open source projects, their licenses are listed in Third-party library licenses.