No description
Find a file
renovate[bot] 8b3b0bbbb4
chore(deps): lock file maintenance vscode npm packages (#3424)
[![Mend
Renovate](https://app.renovatebot.com/images/banner.svg)](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.11` ->
`20.12.12`](https://renovatebot.com/diffs/npm/@types%2fnode/20.12.11/20.12.12)
|
[![age](https://developer.mend.io/api/mc/badges/age/npm/@types%2fnode/20.12.12?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![adoption](https://developer.mend.io/api/mc/badges/adoption/npm/@types%2fnode/20.12.12?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![passing](https://developer.mend.io/api/mc/badges/compatibility/npm/@types%2fnode/20.12.11/20.12.12?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/@types%2fnode/20.12.11/20.12.12?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
| [esbuild](https://togithub.com/evanw/esbuild) | devDependencies |
patch | [`0.21.1` ->
`0.21.4`](https://renovatebot.com/diffs/npm/esbuild/0.21.1/0.21.4) |
[![age](https://developer.mend.io/api/mc/badges/age/npm/esbuild/0.21.4?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![adoption](https://developer.mend.io/api/mc/badges/adoption/npm/esbuild/0.21.4?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![passing](https://developer.mend.io/api/mc/badges/compatibility/npm/esbuild/0.21.1/0.21.4?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/esbuild/0.21.1/0.21.4?slim=true)](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.4`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0214)

[Compare
Source](https://togithub.com/evanw/esbuild/compare/v0.21.3...v0.21.4)

- Update support for import assertions and import attributes in node
([#&#8203;3778](https://togithub.com/evanw/esbuild/issues/3778))

Import assertions (the `assert` keyword) have been removed from node
starting in v22.0.0. So esbuild will now strip them and generate a
warning with `--target=node22` or above:

▲ [WARNING] The "assert" keyword is not supported in the configured
target environment ("node22") [assert-to-with]

            example.mjs:1:40:
1 │ import json from "esbuild/package.json" assert { type: "json" }
                │                                         ~~~~~~
                ╵                                         with

          Did you mean to use "with" instead of "assert"?

Import attributes (the `with` keyword) have been backported to node 18
starting in v18.20.0. So esbuild will no longer strip them with
`--target=node18.N` if `N` is 20 or greater.

-   Fix `for await` transform when a label is present

This release fixes a bug where the `for await` transform, which wraps
the loop in a `try` statement, previously failed to also move the loop's
label into the `try` statement. This bug only affects code that uses
both of these features in combination. Here's an example of some
affected code:

    ```js
    // Original code
    async function test() {
      outer: for await (const x of [Promise.resolve([0, 1])]) {
        for (const y of x) if (y) break outer
        throw 'fail'
      }
    }

    // Old output (with --target=es6)
    function test() {
      return __async(this, null, function* () {
        outer: try {
for (var iter = __forAwait([Promise.resolve([0, 1])]), more, temp,
error; more = !(temp = yield iter.next()).done; more = false) {
            const x = temp.value;
            for (const y of x) if (y) break outer;
            throw "fail";
          }
        } catch (temp) {
          error = [temp];
        } finally {
          try {
            more && (temp = iter.return) && (yield temp.call(iter));
          } finally {
            if (error)
              throw error[0];
          }
        }
      });
    }

    // New output (with --target=es6)
    function test() {
      return __async(this, null, function* () {
        try {
outer: for (var iter = __forAwait([Promise.resolve([0, 1])]), more,
temp, error; more = !(temp = yield iter.next()).done; more = false) {
            const x = temp.value;
            for (const y of x) if (y) break outer;
            throw "fail";
          }
        } catch (temp) {
          error = [temp];
        } finally {
          try {
            more && (temp = iter.return) && (yield temp.call(iter));
          } finally {
            if (error)
              throw error[0];
          }
        }
      });
    }
    ```

- Do additional constant folding after cross-module enum inlining
([#&#8203;3416](https://togithub.com/evanw/esbuild/issues/3416),
[#&#8203;3425](https://togithub.com/evanw/esbuild/issues/3425))

This release adds a few more cases where esbuild does constant folding
after cross-module enum inlining.

    ```ts
    // Original code: enum.ts
    export enum Platform {
      WINDOWS = 'windows',
      MACOS = 'macos',
      LINUX = 'linux',
    }

    // Original code: main.ts
    import { Platform } from './enum';
    declare const PLATFORM: string;
    export function logPlatform() {
      if (PLATFORM == Platform.WINDOWS) console.log('Windows');
      else if (PLATFORM == Platform.MACOS) console.log('macOS');
      else if (PLATFORM == Platform.LINUX) console.log('Linux');
      else console.log('Other');
    }

// Old output (with --bundle '--define:PLATFORM="macos"' --minify
--format=esm)
function
n(){"windows"=="macos"?console.log("Windows"):"macos"=="macos"?console.log("macOS"):"linux"=="macos"?console.log("Linux"):console.log("Other")}export{n
as logPlatform};

// New output (with --bundle '--define:PLATFORM="macos"' --minify
--format=esm)
    function n(){console.log("macOS")}export{n as logPlatform};
    ```

- Pass import attributes to on-resolve plugins
([#&#8203;3384](https://togithub.com/evanw/esbuild/issues/3384),
[#&#8203;3639](https://togithub.com/evanw/esbuild/issues/3639),
[#&#8203;3646](https://togithub.com/evanw/esbuild/issues/3646))

With this release, on-resolve plugins will now have access to the import
attributes on the import via the `with` property of the arguments
object. This mirrors the `with` property of the arguments object that's
already passed to on-load plugins. In addition, you can now pass `with`
to the `resolve()` API call which will then forward that value on to all
relevant plugins. Here's an example of a plugin that can now be written:

    ```js
    const examplePlugin = {
      name: 'Example plugin',
      setup(build) {
        build.onResolve({ filter: /.*/ }, args => {
          if (args.with.type === 'external')
            return { external: true }
        })
      }
    }

    require('esbuild').build({
      stdin: {
        contents: `
          import foo from "./foo" with { type: "external" }
          foo()
        `,
      },
      bundle: true,
      format: 'esm',
      write: false,
      plugins: [examplePlugin],
    }).then(result => {
      console.log(result.outputFiles[0].text)
    })
    ```

- Formatting support for the `@position-try` rule
([#&#8203;3773](https://togithub.com/evanw/esbuild/issues/3773))

Chrome shipped this new CSS at-rule in version 125 as part of the [CSS
anchor positioning
API](https://developer.chrome.com/blog/anchor-positioning-api). With
this release, esbuild now knows to expect a declaration list inside of
the `@position-try` body block and will format it appropriately.

- Always allow internal string import and export aliases
([#&#8203;3343](https://togithub.com/evanw/esbuild/issues/3343))

Import and export names can be string literals in ES2022+. Previously
esbuild forbid any usage of these aliases when the target was below
ES2022. Starting with this release, esbuild will only forbid such usage
when the alias would otherwise end up in output as a string literal.
String literal aliases that are only used internally in the bundle and
are "compiled away" are no longer errors. This makes it possible to use
string literal aliases with esbuild's `inject` feature even when the
target is earlier than ES2022.

###
[`v0.21.3`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0213)

[Compare
Source](https://togithub.com/evanw/esbuild/compare/v0.21.2...v0.21.3)

- Implement the decorator metadata proposal
([#&#8203;3760](https://togithub.com/evanw/esbuild/issues/3760))

This release implements the [decorator metadata
proposal](https://togithub.com/tc39/proposal-decorator-metadata), which
is a sub-proposal of the [decorators
proposal](https://togithub.com/tc39/proposal-decorators). Microsoft
shipped the decorators proposal in [TypeScript
5.0](https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#decorators)
and the decorator metadata proposal in [TypeScript
5.2](https://devblogs.microsoft.com/typescript/announcing-typescript-5-2/#decorator-metadata),
so it's important that esbuild also supports both of these features.
Here's a quick example:

    ```js
    // Shim the "Symbol.metadata" symbol
    Symbol.metadata ??= Symbol('Symbol.metadata')

    const track = (_, context) => {
      (context.metadata.names ||= []).push(context.name)
    }

    class Foo {
      @&#8203;track foo = 1
      @&#8203;track bar = 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
([#&#8203;3768](https://togithub.com/evanw/esbuild/issues/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:

    ```js
    class Foo extends Object {
      @&#8203;(x => x) foo() {
        return Foo
      }
    }
    console.log(new Foo().foo())
    ```

- Fix `tsconfig.json` files inside symlinked directories
([#&#8203;3767](https://togithub.com/evanw/esbuild/issues/3767))

This release fixes an issue with a scenario involving a `tsconfig.json`
file that `extends` another file from within a symlinked directory that
uses the `paths` feature. In that case, the implicit `baseURL` value
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 for `tsconfig.json`
because it's special-cased (the regular path resolver can't be used
because the information inside `tsconfig.json` is involved in path
resolution). Note that this fix no longer applies if the
`--preserve-symlinks` setting is enabled.

###
[`v0.21.2`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0212)

[Compare
Source](https://togithub.com/evanw/esbuild/compare/v0.21.1...v0.21.2)

- Correct `this` in field and accessor decorators
([#&#8203;3761](https://togithub.com/evanw/esbuild/issues/3761))

This release changes the value of `this` in initializers for class field
and accessor decorators from the module-level `this` value to the
appropriate `this` value 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:

    ```js
    const dec = () => function() { this.bar = true }
    class Foo { @&#8203;dec static foo }
    console.log(Foo.bar) // Should be "true"
    ```

- Allow `es2023` as a target environment
([#&#8203;3762](https://togithub.com/evanw/esbuild/issues/3762))

TypeScript recently [added
`es2023`](https://togithub.com/microsoft/TypeScript/pull/58140) as a
compilation target, so esbuild now supports this too. There is no
difference between a target of `es2022` and `es2023` as far as esbuild
is concerned since the 2023 edition of JavaScript doesn't introduce any
new syntax features.

</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:eyJjcmVhdGVkSW5WZXIiOiIzNy4zNjguMTAiLCJ1cGRhdGVkSW5WZXIiOiIzNy4zNjguMTAiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbXX0=-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2024-05-26 22:14:04 +00:00
.cargo ci: run cargo check with --all-features 2024-04-03 16:43:50 +08:00
.github chore: codecov ignore crates/oxc_traverse/src/ancestor.rs 2024-05-26 20:29:07 +08:00
.vscode chore: add some useful informantion log (#1912) 2024-01-06 22:30:01 +08:00
apps/oxlint refactor(cli): move crates/oxc_cli to apps/oxlint (#3413) 2024-05-26 05:00:30 +00:00
crates fix(website): hack schemars to render code snippet in markdown (#3417) 2024-05-26 10:36:53 +00:00
editors/vscode chore(deps): lock file maintenance vscode npm packages (#3424) 2024-05-26 22:14:04 +00:00
fuzz chore(fuzz): add a timeout command 2024-02-05 14:41:14 +08:00
napi/parser refactor(diagnostics): remove export of miette 2024-05-12 11:46:48 +08:00
npm fix(website): hack schemars to render code snippet in markdown (#3417) 2024-05-26 10:36:53 +00:00
tasks chore(deps): lock file maintenance npm packages (#3421) 2024-05-26 18:29:48 +00:00
wasm/parser chore(deps): lock file maintenance npm packages (#3421) 2024-05-26 18:29:48 +00:00
website chore(deps): lock file maintenance website npm packages (#3166) 2024-05-06 09:35:15 +08:00
.git-blame-ignore-revs
.gitignore feat(tasks): shard benchmarks in CI (#2751) 2024-03-18 10:45:44 +08:00
.ignore
.rustfmt.toml chore: move rustfmt.toml -> .rustfmt.toml 2024-05-12 13:14:50 +08:00
.taplo.toml chore: update toml format 2024-05-21 22:15:47 +08:00
.typos.toml chore: fix typos by ignoring no_unknown_property.rs 2024-04-02 16:27:38 +08:00
Cargo.lock fix(website): hack schemars to render code snippet in markdown (#3417) 2024-05-26 10:36:53 +00:00
Cargo.toml fix(website): hack schemars to render code snippet in markdown (#3417) 2024-05-26 10:36:53 +00:00
CHANGELOG.md chore: add CHANGELOG.md 2024-03-26 21:03:22 +08:00
cliff.toml chore: add changelogs via git cliff (#2878) 2024-04-01 20:04:48 +08:00
CONTRIBUTING.md
deny.toml wip 2024-03-05 16:25:14 +08:00
justfile chore(justfile): add wasm build commands 2024-05-26 20:55:49 +08:00
LICENSE
MAINTENANCE.md chore: update MAINTENANCE.md 2024-04-20 16:59:47 +08:00
README.md chore(README): add sponsors 2024-05-04 10:57:53 +08:00
rust-toolchain.toml chore(deps): update dependency rust to v1.78.0 (#3151) 2024-05-03 00:01:42 +08:00
THIRD-PARTY-LICENSE chore(index): fork index_vec crate. (#3092) 2024-04-25 06:09:53 +00:00

OXC Logo

MIT licensed Build Status Code Coverage CodSpeed Badge Sponsors

Discord chat Playground Website

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?

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/*/examples directory.

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

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:

📚 Learning Resources

🤝 Credits

This project was incubated with the assistance of these exceptional mentors and their projects:

❤️ Sponsors

My 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.