---
url: /docs/getting-started.md
---

# Getting Started

## Installation

The easiest way to try SWC is using the [Playground](/playground/index.md).

Otherwise, run the following to download pre-built binaries:


```sh [npm]
npm install -D @swc/cli @swc/core
```

```sh [yarn]
yarn add -D @swc/cli @swc/core
```

```sh [pnpm]
pnpm add -D @swc/cli @swc/core
```

```sh [bun]
bun add -D @swc/cli @swc/core
```

```sh [deno]
deno add -D npm:@swc/cli npm:@swc/core
```

Then, you can transpile your first file and emit to `stdout`:

```bash
npx swc ./file.js
```

## Supported Binaries

SWC can be downloaded and used as a pre-built binary, or built from source. Currently, the following binaries are provided:

- Mac (Apple Silicon)
- Mac (x64)
- Linux (x86\_64)
- Linux (aarch64)
- Linux (armv7)
- Alpine Linux (also install `@swc/core-linux-musl`)
- Android (aarch64)
- Windows (win32-x64)
- Windows (ia32)



---
url: /docs/usage/cli.md
---

# @swc/cli

## Usage

Run the following to download pre-built binaries:


```sh [npm]
npm install -D @swc/cli @swc/core
```

```sh [yarn]
yarn add -D @swc/cli @swc/core
```

```sh [pnpm]
pnpm add -D @swc/cli @swc/core
```

```sh [bun]
bun add -D @swc/cli @swc/core
```

```sh [deno]
deno add -D npm:@swc/cli npm:@swc/core
```

Then, you can transpile your files:

```sh
# Transpile one file and emit to stdout
npx swc ./file.js

# Transpile one file and emit to `output.js`
npx swc ./file.js -o output.js

# Transpile and write to /output dir
npx swc ./my-dir -d output
```

## Flow input

To compile Flow code with the CLI, point `swc` at a `.swcrc` file that sets
`jsc.parser.syntax` to `"flow"`:

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "flow"
    }
  }
}
```

```sh
npx swc input.js --config-file .swcrc -o output.js
```

For JSX-flavored Flow files, set `jsx: true` and compile `.jsx` inputs with the
same config. See the [Flow guide](/docs/usage/flow.md) for the full list of parser
options.

## Options

### `--filename` (-f)

Filename to use when reading from stdin. This will be used in source maps and errors.

```sh
npx swc -f input.js
```

### `--config-file`

Path to a `.swcrc` file to use.

```sh
npx swc input.js --config-file .swcrc
```

### `--env-name`

The name of the 'env' to use when loading configs and plugins. Defaults to the value of `SWC_ENV`, or else `NODE_ENV`, or else `development`.

```sh
npx swc input.js --env-name='test'
```

### `--no-swcrc`

Whether or not to look up `.swcrc` files.

```sh
npx swc input.js --no-swcrc
```

### `--ignore`

List of glob paths to **not** compile.

```sh
npx swc src --ignore **/*.test.js
```

### `--only`

List of glob paths to **only** compile

Example:

```sh
npx swc src --only **/*.js
```

### `--watch` (-w)

To automatically recompile files on changes, install `chokidar`:


```sh [npm]
npm install -D chokidar
```

```sh [yarn]
yarn add -D chokidar
```

```sh [pnpm]
pnpm add -D chokidar
```

```sh [bun]
bun add -D chokidar
```

```sh [deno]
deno add -D npm:chokidar
```

Then, add the `-w` flag:

```sh
npx swc input.js -w
```

### `--quiet` (-q)

Suppress compilation output.

```sh
npx swc input.js -q
```

### `--source-maps` (-s)

Values: `true|false|inline|both`

```sh
npx swc input.js -s
```

### `--source-map-target`

Define the `file` for the source map.

```sh
npx swc input.js -s --source-map-target input.map.js
```

### `--source-file-name`

Set `sources[0]` on returned source map

### `--source-root`

The root from which all sources are relative.

### `--out-file` (-o)

Compile all input files into a single file.

```sh
npx swc input.js -o output.js
```

### `--out-dir` (-d)

Compile an input directory of modules into an output directory.

```sh
npx swc src -d dist
```

### `--copy-files` (-D)

When compiling a directory, copy over non-compilable files.

```sh
npx swc src --copy-files
```

### `--include-dotfiles`

Include dotfiles when compiling and copying non-compilable files.

```sh
npx swc src --include-dotfiles
```

### `--config` (-C)

Override a config from `.swcrc` file.

```sh
npx swc src -C module.type=amd -C module.moduleId=hello
```

### `--sync`

Invoke swc synchronously. Useful for debugging.

```sh
npx swc src --sync
```

### `--log-watch-compilation`

Log a message when a watched file is successfully compiled.

```sh
npx swc input.js --log-watch-compilation
```

### `--extensions`

Use specific extensions.

### `--strip-leading-paths`

Remove the leading directory (including all parent relative paths) when building the final output path. As an example it compiles all modules under `src` folder to `dist` folder, without create the `src` folder inside of `dist`.

```sh
npx swc src -d dist --strip-leading-paths
```

## use in nodejs script

```js
const { swcDir } = require('@swc/cli');

const swcOptions = {
    jsc: {
        target: 'esnext',
        externalHelpers: true,
    },
    module: {
        type: 'commonjs',
    },
    sourceMaps: true,
};

swcDir({
    cliOptions: {
        outDir: './dist',
        watch: true,
        filenames: ['./src'],
        extensions: ['.ts'],
        stripLeadingPaths: true,
    },
    swcOptions,
    callbacks: {
        onSuccess: e => {
            console.log(e);
        },
        onFail: e => {
            console.log(e);
        },
        onWatchReady: () => {},
    },
});
```

Please note that when using `callbacks`, the `--quiet (-q)` will always be true.

### `--out-file-extension`

Use a specific extension for the output files.

As an example, if you want to render your es6 output to `.mjs` file extensions, you could call:

```shell
npx swc input.js --out-file-extension mjs
```

Please note that if you are compiling multiple files, you will also need to make sure that your imports are resolved with the appropriate
extension. You can do so by making use of the `resolveFully` and `outFileExtension` module options:

```json
{
  "module": {
    "resolveFully": true,
    "outFileExtension": "mjs"
  }
}
```



---
url: /docs/usage/core.md
---

# @swc/core

These are the core SWC APIs mainly useful for build tool authors.

## transform

`@swc/core` provides appropriate `.d.ts` file, so you may not need this. Returns `Promise<{ code: string, map?: string }>`

```ts twoslash
import * as swc from "@swc/core";

swc
  .transform("source code", {
    // Some options cannot be specified in .swcrc
    filename: "input.js",
    sourceMaps: true,
    // Input files are treated as module by default.
    isModule: false,

    // All options below can be configured via .swcrc
    jsc: {
      parser: {
        syntax: "ecmascript",
      },
      transform: {},
    },
  })
  .then((output) => {
    output.code; // transformed code
    output.map; // source map (in string)
  });
```

### Flow input

To transform Flow code, set `jsc.parser.syntax` to `"flow"`. SWC will parse
Flow syntax and strip type-only constructs as part of the transform pipeline.

```ts twoslash
import * as swc from "@swc/core";

swc.transform("const value: number = 1;", {
  jsc: {
    parser: {
      syntax: "flow",
    },
  },
});
```

See the [Flow guide](/docs/usage/flow.md) for `.swcrc`, CLI, and parser options.

### transformSync

Returns `{ code: string, map?: string }`

### transformFile

Returns `Promise<{ code: string, map?: string }>`

### transformFileSync

Returns `{ code: string, map?: string }`

## parse

Returns `Promise<Script | Module>`

```ts twoslash
import * as swc from "@swc/core";

swc
  .parse("source code", {
    syntax: "ecmascript", // "ecmascript" | "typescript" | "flow"
    comments: false,
    script: true,

    // Defaults to es3
    target: "es3",

    // Input source code are treated as module by default
    isModule: false,
  })
  .then((module) => {
    module.type // file type
    //     ^?
    module.body; // AST
  })
```


Type Declarations

```ts
export declare function parse(src: string, options: ParseOptions & {
    isModule: false;
}): Promise<Script>;
export declare function parse(src: string, options?: ParseOptions): Promise<Module>;
export declare function parseSync(src: string, options: ParseOptions & {
    isModule: false;
}): Script;
export declare function parseSync(src: string, options?: ParseOptions): Module;
export declare function parseFile(path: string, options: ParseOptions & {
    isModule: false;
}): Promise<Script>;
export declare function parseFile(path: string, options?: ParseOptions): Promise<Module>;
export declare function parseFileSync(path: string, options: ParseOptions & {
    isModule: false;
}): Script;
export declare function parseFileSync(path: string, options?: ParseOptions): Module;

export interface Module extends Node, HasSpan, HasInterpreter {
    type: "Module";
    body: ModuleItem[];
}
export interface Script extends Node, HasSpan, HasInterpreter {
    type: "Script";
    body: Statement[];
}
export declare type ParseOptions = ParserConfig & {
  comments?: boolean;
  script?: boolean;
  /**
   * Defaults to es3.
   */
  target?: JscTarget;
};
export declare type JscTarget = "es3" | "es5" | "es2015" | "es2016" | "es2017" | "es2018" | "es2019" | "es2020" | "es2021" | "es2022";
export declare type ParserConfig = TsParserConfig | EsParserConfig | FlowParserConfig;
export interface TsParserConfig {
    syntax: "typescript";
    /**
     * Defaults to `false`.
     */
    tsx?: boolean;
    /**
     * Defaults to `false`.
     */
    decorators?: boolean;
    /**
     * Defaults to `false`
     */
    dynamicImport?: boolean;
}
export interface FlowParserConfig {
    syntax: "flow";
    /**
     * Defaults to `false`.
     */
    jsx?: boolean;
    /**
     * Defaults to `false`.
     */
    all?: boolean;
    /**
     * Defaults to `false`.
     */
    requireDirective?: boolean;
    /**
     * Defaults to `false`.
     */
    enums?: boolean;
    /**
     * Defaults to `false`.
     */
    decorators?: boolean;
    /**
     * Defaults to `false`.
     */
    components?: boolean;
    /**
     * Defaults to `false`.
     */
    patternMatching?: boolean;
}
export interface EsParserConfig {
    syntax: "ecmascript";
    /**
     * Defaults to false.
     */
    jsx?: boolean;
    /**
     * Defaults to `false`
     */
    functionBind?: boolean;
    /**
     * Defaults to `false`
     */
    decorators?: boolean;
    /**
     * Defaults to `false`
     */
    decoratorsBeforeExport?: boolean;
    /**
     * Defaults to `false`
     */
    exportDefaultFrom?: boolean;
    /**
     * Defaults to `false`
     */
    importAssertions?: boolean;
}
```

### parseSync

Returns `Script | Module`

### parseFile

Returns `Promise<Script | Module>`

### parseFileSync

Returns `Script | Module`

## minify

Returns `Promise<Output>`

```ts
const swc = require('@swc/core')

swc
  .minify('source code', opts?: JsMinifyOptions)
  .then(output => {
    output.code // transformed code
    output.map // sourcemap (in string)
  })
```


Type Declarations

```ts
export declare function minify(src: string, opts?: JsMinifyOptions): Promise<Output>;
export declare function minifySync(src: string, opts?: JsMinifyOptions): Output;

export interface Output {
    code: string;
    map?: string;
}
export declare type TerserEcmaVersion = 5 | 2015 | 2016 | string | number;
export interface JsMinifyOptions {
    compress?: TerserCompressOptions | boolean;
    mangle?: TerserMangleOptions | boolean;
    ecma?: TerserEcmaVersion;
    keep_classnames?: boolean;
    keep_fnames?: boolean;
    module?: boolean | "unknown";
    safari10?: boolean;
    toplevel?: boolean;
    sourceMap?: boolean;
    outputPath?: string;
    inlineSourcesContent?: boolean;
}
export interface TerserCompressOptions {
    arguments?: boolean;
    arrows?: boolean;
    booleans?: boolean;
    booleans_as_integers?: boolean;
    collapse_vars?: boolean;
    comparisons?: boolean;
    computed_props?: boolean;
    conditionals?: boolean;
    dead_code?: boolean;
    defaults?: boolean;
    directives?: boolean;
    drop_console?: boolean;
    drop_debugger?: boolean;
    ecma?: TerserEcmaVersion;
    evaluate?: boolean;
    expression?: boolean;
    global_defs?: any;
    hoist_funs?: boolean;
    hoist_props?: boolean;
    hoist_vars?: boolean;
    ie8?: boolean;
    if_return?: boolean;
    inline?: 0 | 1 | 2 | 3;
    join_vars?: boolean;
    keep_classnames?: boolean;
    keep_fargs?: boolean;
    keep_fnames?: boolean;
    keep_infinity?: boolean;
    loops?: boolean;
    negate_iife?: boolean;
    passes?: number;
    properties?: boolean;
    pure_getters?: any;
    pure_funcs?: string[];
    reduce_funcs?: boolean;
    reduce_vars?: boolean;
    sequences?: any;
    side_effects?: boolean;
    switches?: boolean;
    top_retain?: any;
    toplevel?: any;
    typeofs?: boolean;
    unsafe_passes?: boolean;
    unsafe_arrows?: boolean;
    unsafe_comps?: boolean;
    unsafe_function?: boolean;
    unsafe_math?: boolean;
    unsafe_symbols?: boolean;
    unsafe_methods?: boolean;
    unsafe_proto?: boolean;
    unsafe_regexp?: boolean;
    unsafe_undefined?: boolean;
    unused?: boolean;
    module?: boolean;
}
export interface TerserMangleOptions {
    props?: TerserManglePropertiesOptions;
    top_level?: boolean;
    keep_class_names?: boolean;
    keep_fn_names?: boolean;
    keep_private_props?: boolean;
    ie8?: boolean;
    safari10?: boolean;
    reserved?: string[];
}
export interface TerserManglePropertiesOptions {
}
```

### minifySync

Returns `Output`

## Options

```ts
/**
 * Programmatic options.
 */
interface Options extends Config {
  /**
   * If true, a file is parsed as a script instead of module.
   */
  script?: boolean;
  /**
   * The working directory that all paths in the programmatic
   * options will be resolved relative to.
   *
   * Defaults to `process.cwd()`.
   */
  cwd?: string;
  caller?: CallerOptions;
  /** The filename associated with the code currently being compiled,
   * if there is one. The filename is optional, but not all of Swc's
   * functionality is available when the filename is unknown, because a
   * subset of options rely on the filename for their functionality.
   *
   * The three primary cases users could run into are:
   *
   * - The filename is exposed to plugins. Some plugins may require the
   * presence of the filename.
   * - Options like "test", "exclude", and "ignore" require the filename
   * for string/RegExp matching.
   * - .swcrc files are loaded relative to the file being compiled.
   * If this option is omitted, Swc will behave as if swcrc: false has been set.
   */
  filename?: string;
  /**
   * The initial path that will be processed based on the "rootMode" to
   * determine the conceptual root folder for the current Swc project.
   * This is used in two primary cases:
   *
   * - The base directory when checking for the default "configFile" value
   * - The default value for "swcrcRoots".
   *
   * Defaults to `opts.cwd`
   */
  root?: string;
  /**
   * This option, combined with the "root" value, defines how Swc chooses
   * its project root. The different modes define different ways that Swc
   * can process the "root" value to get the final project root.
   *
   * "root" - Passes the "root" value through as unchanged.
   * "upward" - Walks upward from the "root" directory, looking for a directory
   * containing a swc.config.js file, and throws an error if a swc.config.js
   * is not found.
   * "upward-optional" - Walk upward from the "root" directory, looking for
   * a directory containing a swc.config.js file, and falls back to "root"
   *  if a swc.config.js is not found.
   *
   *
   * "root" is the default mode because it avoids the risk that Swc
   * will accidentally load a swc.config.js that is entirely outside
   * of the current project folder. If you use "upward-optional",
   * be aware that it will walk up the directory structure all the
   * way to the filesystem root, and it is always possible that someone
   * will have a forgotten swc.config.js in their home directory,
   * which could cause unexpected errors in your builds.
   *
   *
   * Users with monorepo project structures that run builds/tests on a
   * per-package basis may well want to use "upward" since monorepos
   * often have a swc.config.js in the project root. Running Swc
   * in a monorepo subdirectory without "upward", will cause Swc
   * to skip loading any swc.config.js files in the project root,
   * which can lead to unexpected errors and compilation failure.
   */
  rootMode?: "root" | "upward" | "upward-optional";
  /**
   * The current active environment used during configuration loading.
   * This value is used as the key when resolving "env" configs,
   * and is also available inside configuration functions, plugins,
   * and presets, via the api.env() function.
   *
   * Defaults to `process.env.SWC_ENV || process.env.NODE_ENV || "development"`
   */
  envName?: string;
  /**
   * Defaults to searching for a default `.swcrc` file, but can
   * be passed the path of any JS or JSON5 config file.
   *
   *
   * NOTE: This option does not affect loading of .swcrc files,
   * so while it may be tempting to do configFile: "./foo/.swcrc",
   * it is not recommended. If the given .swcrc is loaded via the
   * standard file-relative logic, you'll end up loading the same
   * config file twice, merging it with itself. If you are linking
   * a specific config file, it is recommended to stick with a
   * naming scheme that is independent of the "swcrc" name.
   *
   * Defaults to `path.resolve(opts.root, ".swcrc")`
   */
  configFile?: string | boolean;
  /**
   * true will enable searching for configuration files relative to the "filename" provided to Swc.
   *
   * A swcrc value passed in the programmatic options will override one set within a configuration file.
   *
   * Note: .swcrc files are only loaded if the current "filename" is inside of
   *  a package that matches one of the "swcrcRoots" packages.
   *
   *
   * Defaults to true as long as the filename option has been specificed
   */
  swcrc?: boolean;
  /**
   * By default, Babel will only search for .babelrc files within the "root" package
   *  because otherwise Babel cannot know if a given .babelrc is meant to be loaded,
   *  or if it's "plugins" and "presets" have even been installed, since the file
   *  being compiled could be inside node_modules, or have been symlinked into the project.
   *
   *
   * This option allows users to provide a list of other packages that should be
   * considered "root" packages when considering whether to load .babelrc files.
   *
   *
   * For example, a monorepo setup that wishes to allow individual packages
   * to have their own configs might want to do
   *
   *
   *
   * Defaults to `opts.root`
   */
  swcrcRoots?: boolean | MatchPattern | MatchPattern[];
  /**
   * `true` will attempt to load an input sourcemap from the file itself, if it
   * contains a //# sourceMappingURL=... comment. If no map is found, or the
   * map fails to load and parse, it will be silently discarded.
   *
   *  If an object is provided, it will be treated as the source map object itself.
   *
   * Defaults to `true`.
   */
  inputSourceMap?: boolean | string;
  /**
   * The name to use for the file inside the source map object.
   *
   * Defaults to `path.basename(opts.filenameRelative)` when available, or `"unknown"`.
   */
  sourceFileName?: string;
  /**
   * The sourceRoot fields to set in the generated source map, if one is desired.
   */
  sourceRoot?: string;
  plugin?: Plugin;
  isModule?: boolean | 'unknown';
  /**
   * Destination path. Note that this value is used only to fix source path
   * of source map files and swc does not write output to this path.
   */
  outputPath?: string;
}
```

Where `Config` is defined as:

```ts
export interface Config {
  /**
   * Note: The type is string because it follow rust's regex syntax.
   */
  test?: string | string[];
  /**
   * Note: The type is string because it follow rust's regex syntax.
   */
  exclude?: string | string[];
  env?: EnvConfig;
  jsc?: JscConfig;
  module?: ModuleConfig;
  minify?: boolean;
  /**
   * - true to generate a sourcemap for the code and include it in the result object.
   * - "inline" to generate a sourcemap and append it as a data URL to the end of the code, but not include it in the result object.
   *
   * `swc-cli` overloads some of these to also affect how maps are written to disk:
   *
   * - true will write the map to a .map file on disk
   * - "inline" will write the file directly, so it will have a data: containing the map
   * - Note: These options are bit weird, so it may make the most sense to just use true
   *  and handle the rest in your own code, depending on your use case.
   */
  sourceMaps?: boolean | "inline";
  inlineSourcesContent?: boolean;
}
```



---
url: /docs/usage/flow.md
---

# Flow

SWC can parse Flow syntax and strip Flow type-only constructs during transform.

This guide covers the most common ways to use Flow support:

- `.swcrc`
- `@swc/core`
- `@swc/cli`

## `.swcrc`

Configure the parser with `syntax: "flow"`:

```json title=".swcrc"
{
  "$schema": "https://swc.rs/schema.json",
  "jsc": {
    "parser": {
      "syntax": "flow",
      "jsx": false
    }
  }
}
```

For Flow code that uses a file pragma, enable `requireDirective`:

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "flow",
      "requireDirective": true
    }
  }
}
```

Other supported Flow parser options map to the Flow parser configuration in SWC:

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "flow",
      "all": false,
      "enums": false,
      "decorators": false,
      "components": false,
      "patternMatching": false
    }
  }
}
```

## `@swc/core`

Use `jsc.parser.syntax = "flow"` when transforming Flow input:

```ts twoslash
import * as swc from "@swc/core";

swc
  .transform("const value: number = 1;", {
    filename: "input.js",
    jsc: {
      parser: {
        syntax: "flow",
      },
    },
  })
  .then((output) => {
    output.code; // const value = 1;
  });
```

You can also parse Flow syntax directly:

```ts twoslash
import * as swc from "@swc/core";

swc
  .parse("const value: number = 1;", {
    syntax: "flow",
  })
  .then((module) => {
    module.type;
    module.body;
  });
```

## `@swc/cli`

Point the CLI at a `.swcrc` with `syntax: "flow"`:

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "flow"
    }
  }
}
```

```sh
npx swc input.js --config-file .swcrc -o output.js
```

For JSX-flavored Flow input, set `jsx: true` and compile `.jsx` inputs with the
same config:

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "flow",
      "jsx": true
    }
  }
}
```

```sh
npx swc component.jsx --config-file .swcrc -o component.js
```



---
url: /docs/usage/wasm.md
---

# @swc/wasm-web

This modules allows you to synchronously transform code inside the browser using WebAssembly.

## Usage

You must first initialize the module before you can use it.

```tsx title="App.jsx" twoslash
import { useEffect, useState } from "react";
import initSwc, { transformSync } from "@swc/wasm-web";

export default function App() {
  const [initialized, setInitialized] = useState(false);

  useEffect(() => {
    async function importAndRunSwcOnMount() {
      await initSwc();
      setInitialized(true);
    }
    importAndRunSwcOnMount();
  }, []);

  function compile() {
    if (!initialized) {
      return;
    }
    const result = transformSync(`console.log('hello')`, {});
    console.log(result);
  }

  return (
    <div className="App">
      <button onClick={compile}>Compile</button>
    </div>
  );
}
```



---
url: /docs/usage/jest.md
---

# @swc/jest

To make your Jest tests run faster, you can swap out the default JavaScript-based runner (`ts-jest`) for a [drop-in Rust replacement](https://github.com/swc-project/pkgs/tree/main/packages/jest) using SWC.

## Installation


```sh [npm]
npm install -D jest @swc/core @swc/jest
```

```sh [yarn]
yarn add -D jest @swc/core @swc/jest
```

```sh [pnpm]
pnpm add -D jest @swc/core @swc/jest
```

```sh [bun]
bun add -D jest @swc/core @swc/jest
```

```sh [deno]
deno add -D npm:jest npm:@swc/core npm:@swc/jest
```

## Usage

Inside `jest.config.js`, configure Jest to use SWC:

```js title="jest.config.js"
module.exports = {
  transform: {
    '^.+\\.(t|j)sx?$': '@swc/jest',
  },
}
```

It will load the SWC configuration from `.swcrc` by default. You also can customize it:

```js title="jest.config.js"
const fs = require('fs')

const config = JSON.parse(fs.readFileSync(`${__dirname}/.swcrc`, 'utf-8'))

module.exports = {
  transform: {
    '^.+\\.(t|j)sx?$': ['@swc/jest', { ...config, /* custom configuration in Jest */ }],
  },
}
```

## Q & A

### Q: Jest uses CommonJS by default. But I want to use ESM

A: Setup Jest following this [Guide](https://jestjs.io/docs/ecmascript-modules).

For JavaScript, edit `package.json` as follows:

```json title="package.json"
{
  // ...
  "type": "module"
}
```

For TypeScript, edit `jest.config.js` as follows:

```js title="jest.config.js"
module.exports = {
  // ...
  extensionsToTreatAsEsm: ['.ts', '.tsx'],
}
```

Run test with `--experimental-vm-modules`:

```sh
cross-env NODE_OPTIONS=--experimental-vm-modules jest

# or
node --experimental-vm-modules ./node_modules/jest/bin/jest.js
```

### Q: What ECMAScript target is set by `jsc.target`?

A: By default, the version supported by your Node runtime.

| Node version | Default `jsc.target` |
| ------------ | -------------------- |
| 12           | 'es2018'             |
| 13           | 'es2019'             |
| 14           | 'es2020'             |
| 15           | 'es2021'             |
| 16           | 'es2021'             |
| 17           | 'es2022'             |
| 18           | 'es2023'             |

You can customize this by setting an explicit version in `jest.config.js`:

```js title="jest.config.js"
module.exports = {
    transform: {
        "^.+\\.(t|j)sx?$": [
            "@swc/jest",
            {
                jsc: {
                    target: "es2021",
                },
            },
        ],
    },
}
```



---
url: /docs/usage/swc-loader.md
---

# swc-loader

This module allows you to use SWC with webpack.

For Rspack users, you can use Rspack's [builtin:swc-loader](https://rspack.rs/guide/features/builtin-swc-loader), without the need to install the swc-loader package.

## Installation


```sh [npm]
npm install -D @swc/core swc-loader
```

```sh [yarn]
yarn add -D @swc/core swc-loader
```

```sh [pnpm]
pnpm add -D @swc/core swc-loader
```

```sh [bun]
bun add -D @swc/core swc-loader
```

```sh [deno]
deno add -D npm:@swc/core npm:swc-loader
```

## Usage

```js title="webpack.config.js"
module: {
  rules: [
    {
      test: /\.m?js$/,
      exclude: /(node_modules)/,
      use: {
        // `.swcrc` can be used to configure swc
        loader: "swc-loader"
      }
    }
  ]
}
```

### Options

Loader options are passed through to SWC as if they were part of your `.swcrc`.

For instance, [to configure `browserslist`-based `targets` for compilation](https://swc.rs/docs/configuration/compilation#env) and see the effect:

```js
{
  use: {
    loader: "swc-loader",
    options: {
      env: {
        targets: "defaults",
        debug: true
      }
    }
  }
}
```

### React Development

The [`jsc.transform.react.development`](/docs/configuration/compilation.md#jsctransformreactdevelopment) option is automatically set based on the [webpack `mode`](https://webpack.js.org/configuration/mode/).

### With babel-loader

When used with babel-loader, the parseMap option must be set to true.

```js title="webpack.config.js"
module: {
  rules: [
    {
      test: /\.m?js$/,
      exclude: /(node_modules)/,
      use: {
        loader: "swc-loader",
        options: {
          parseMap: true
        }
      }
    }
  ]
}
```



---
url: /docs/usage/html.md
---

# @swc/html

## Installation


```sh [npm]
npm install -D @swc/html
```

```sh [yarn]
yarn add -D @swc/html
```

```sh [pnpm]
pnpm add -D @swc/html
```

```sh [bun]
bun add -D @swc/html
```

```sh [deno]
deno add -D npm:@swc/html
```

## Usage

### `minify()` / `minifySync()`

If you are minifying a whole HTML document, you can use the `minify()` function.

```ts twoslash
import { minify } from '@swc/html';

const html = await minify('<div>Hello, world!</div>', {

});
```

### `minifyFragment()` / `minifyFragmentSync()`

If you are minifying a fragment of HTML, you can use the `minifyFragment()` function.

```ts twoslash
import { minifyFragment } from '@swc/html';

const html = await minifyFragment('<div>Hello, world!</div>', {

});
```



---
url: /docs/usage/bundling.md
---

# Bundling (swcpack)


🚧

This feature will be dropped in v2, in favor of SWC-based bundlers like [Parcel 2](https://parceljs.org/), [Turbopack](https://turbo.build/pack/docs), [Rspack](https://rspack.rs/), [fe-farm](https://www.farmfe.org/).
Please use one of the bundlers instead.

SWC is able to bundle multiple JavaScript or TypeScript files into one.

This feature is currently named `spack`, but will be renamed to `swcpack` in `v2`. `spack.config.js` will be deprecated for `swcpack.config.js`.

View a [basic example of bundling](https://github.com/swc-project/pkgs/tree/main/packages/cli/examples/spack-basic).

## Usage


```sh [npm]
npm install -D @swc/cli @swc/core
```

```sh [yarn]
yarn add -D @swc/cli @swc/core
```

```sh [pnpm]
pnpm add -D @swc/cli @swc/core
```

```sh [bun]
bun add -D @swc/cli @swc/core
```

```sh [deno]
deno add -D npm:@swc/cli npm:@swc/core
```

Create a `spack.config.js` file and run:

```bash
npx spack
```

## Configuration

To see all options, [view the configuration](/docs/configuration/bundling.md).

## Features

### Compact Output

Just like `rollup`, SWC emits compact output.

```js title="a.js"
console.log("loading A");
export function a() {
  console.log("use!");
}
```

```js title="lib.js"
import { a } from "./a";
a();
```

becomes:

```js title="output.js"
console.log("loading A");
function a() {
  console.log("use!");
}
a();
```

SWC was designed with merging in mind, so naming collisions between multiple files are automatically handled.

### Tree Shaking

Just like other modern bundlers, SWC can remove unused exports.

### Import Deglobbing

To aid with tree-shaking, SWC deglobs imports if possible.

```js
import * as lib from "lib";
lib.foo();
```

behaves exactly same as:

```js
import { foo } from "lib";
foo();
```

This preserves all side effects.

### CommonJS Support

SWC supports importing CommonJS modules and emits more compact output than webpack.

```js title="source.js"
import * as lib from "lib";
console.log(lib); // Prevent dce
```

If the `lib` above is a CommonJS module, it's transcompiled to:

```js title="output.js"
const load = __spack_require.bind(void 0, function (module, exports) {
  // Code from lib goes here
});
const lib = load();
console.log(lib); // Prevent dce
```

### Optimizations

- Global Inlining (e.g. `process.env.NODE_ENV`)
- Inlining
- Constant propagation
- Dead code elimination

The tree shaking described above is using the dead code elimination pass. Currently, SWC can deduce:

```js title="source.js"
let b = 2;
let a = 1;
if (b) {
  a = 2;
}
let c;
if (a) {
  c = 3;
}
console.log(c);
```

into:

```js title="output.js"
console.log(3);
```

### High Performance

Performance is a priority for SWC. It's very fast because it uses all CPU cores and is optimized by `llvm`.

### Multiple Entries Support

```js title="spack.config.js"
const { config } = require("@swc/core/spack");

module.exports = config({
  entry: {
    web: __dirname + "/src/web.ts",
    android: __dirname + "/src/android.ts",
  },
  output: {
    path: __dirname + "/lib",
  },
  module: {},
});
```

### Built-in Chunking

Using the same config as above, if `android.ts` and `web.ts` both references the same file, it will be extracted as a separate chunk and `web.ts` and `android.ts` will import it.



---
url: /docs/configuration/swcrc.md
---

💡

SWC provides an official JSON Schema for the configuration file.
```json title=".swcrc"
{
  "$schema": "https://swc.rs/schema.json",
}
```

# Configuring SWC

SWC can be configured with an `.swcrc` file.

## Compilation

Compilation works out of the box with SWC and does not require customization. Optionally, you can override the configuration. Here are the defaults:

```jsonc title=".swcrc"
{
  "$schema": "https://swc.rs/schema.json",
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": false,
      "dynamicImport": false,
      "privateMethod": false,
      "functionBind": false,
      "exportDefaultFrom": false,
      "exportNamespaceFrom": false,
      "decorators": false,
      "decoratorsBeforeExport": false,
      "topLevelAwait": false,
      "importMeta": false
    },
    "transform": null,
    "target": "es5",
    "loose": false,
    "externalHelpers": false,
    // Requires v1.2.50 or upper and requires target to be es2016 or upper.
    "keepClassNames": false
  },
  "minify": false
}
```

Read more about [configuring compilation](/docs/configuration/compilation.md).

## Supported Browsers

Starting with `v1.1.10`, you can now use `browserslist` to automatically configure supported browsers.

### Usage

First, install `browserslist`. Then, update your `.swcrc`:

```json title=".swcrc"
{
  "env": {
    "targets": {
      "chrome": "79"
    },
    "mode": "entry",
    "coreJs": "3.22"
  }
}
```

Read more about [configuring supported browsers](/docs/configuration/supported-browsers.md).

## Modules

Read more about [configuring modules](/docs/configuration/modules.md).

## Minification

Starting with `v1.2.67`, you can configure SWC to minify your code by enabling `minify` in your `.swcrc` file:

```json title=".swcrc"
{
  "minify": true
}
```

Read more about [configuring the JavaScript minifier](/docs/configuration/minification.md).



---
url: /docs/configuration/compilation.md
---

💡

SWC provides an official JSON Schema for the configuration file.
```json title=".swcrc"
{
  "$schema": "https://swc.rs/schema.json",
}
```

# Compilation

Compilation works out of the box with SWC and does not require customization. Optionally, you can override the configuration. Here are the defaults:

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": false,
      "dynamicImport": false,
      "privateMethod": false,
      "functionBind": false,
      "exportDefaultFrom": false,
      "exportNamespaceFrom": false,
      "decorators": false,
      "decoratorsBeforeExport": false,
      "topLevelAwait": false,
      "importMeta": false,
      "preserveAllComments": false
    },
    "transform": null,
    "target": "es5",
    "loose": false,
    "externalHelpers": false,
    // Requires v1.2.50 or upper and requires target to be es2016 or upper.
    "keepClassNames": false
  },
  "isModule": false
}
```

## env

SWC has an alternative for `preset-env`.
You can

- Set target browsers
- Use `browserslist`
- Control transforms

with `env` entry.
Note that this does not work with `jsc.target`.

### `env.targets`

Possible values:

- Query: `string`

Example:

```json title=".swcrc"
{
    "jsc": {
        "parser": {
            "syntax": "typescript",
            "tsx": true,
        },
        "externalHelpers": true
    },
    "env": {
        "targets": "Chrome >= 48"
    }
}

```

- Queries: `string[]`

- Version per browser: `Map<String, Version>`

Example of targeting `chrome 79`.

```json title=".swcrc"
{
    "env": {
        "targets": {
            "chrome": "79",
        }
    },
}
```

### `env.mode`

Optional.
Possible values: `"usage" | "entry" | false`, defaults to `false`.

### `env.debug`

Optional.
Type: Bool

Enable debug logging.

### `env.dynamicImport`

Optional.
Type: Bool

### `env.loose`

Optional.
Type: Bool

Enable loose mode. See [jsc.loose](#jscloose) also.

### `env.skip`

Optional.
Type: `string[]`

### `env.include`

Optional.
Type: `string[]`

Feature or module to include.

Example of enabling `async`/`yield` transform while targeting chrome 79.

```json title=".swcrc"
{
    "env": {
        "targets": {
            "chrome": "79",
        },
        "include": [
            "transform-async-to-generator",
            "transform-regenerator",
        ],
    },
}
```

### `env.exclude`

Optional.
Type: `string[]`

Feature or module to exclude.

### `env.coreJs`

Optional.
Type: `string`

```json title=".swcrc"
{
    "jsc": {
        "parser": {
            "syntax": "ecmascript",
            "jsx": true
        }
    },
    "env": {
        "mode": "usage",
        "coreJs": "3.26.1"
    }
}
```

### `env.path`

Optional.
Currently noop.

### `env.shippedProposals`

Optional.
Type: Bool

### `env.forceAllTransforms`

Optional.
Type: Bool

### `env.bugfixes`

Optional.
Type: Bool

Enable bugfix passes.

## jsc.externalHelpers

```json title=".swcrc"
{
  "jsc": {
    "externalHelpers": true
  }
}
```

The output code may depend on helper functions to support the target environment. By default, a helper function is inlined into the output files where it is required.

By setting `"externalHelpers": true` SWC will inject import statements for these helpers from the `@swc/helpers` package instead of inlining them.

While bundling, this option will greatly reduce your file size.

You must add `@swc/helpers` as a dependency in addition to `@swc/core`.


⚠️

When using `externalHelpers`, you might want to also configure [`"isModule": "unknown"`](#ismodule).
By default, SWC will inject helpers methods with ESM style imports.
So if your file is a commonjs module for example, then SWC will still inject ESM import statements for the helper methods and you'll have a file with mixed ESM and CommonJS imports which can lead to runtime errors.
Setting `"isModule": "unknown"` will make SWC infer the module type of each file by reading it's import/export syntax and inject the helper imports with esm/commojs import statements accordingly.

## jsc.parser

### typescript

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": false,
      "dynamicImport": false
    }
  }
}
```

### flow

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "flow",
      "jsx": false,
      "all": false,
      "requireDirective": false,
      "enums": false,
      "decorators": false,
      "components": false,
      "patternMatching": false
    }
  }
}
```

See the [Flow guide](/docs/usage/flow.md) for `@swc/core`, CLI, and `.swcrc`
examples.

### ecmascript

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": false,
      "dynamicImport": false,
      "privateMethod": false,
      "functionBind": false,
      "classPrivateProperty": false,
      "exportDefaultFrom": false,
      "exportNamespaceFrom": false,
      "decorators": false,
      "decoratorsBeforeExport": false,
      "importMeta": false
    }
  }
}
```

## jsc.target

Starting from `@swc/core` v1.0.27, you can specify the target environment by using the field.

```json title=".swcrc"
{
  "jsc": {
    // Disable es3 / es5 / es2015 transforms
    "target": "es2016"
  }
}
```

## jsc.loose

Starting from `@swc/core` v1.1.4, you can enable "loose" transformations by enabling `jsc.loose` which works like `babel-preset-env` [loose mode](https://2ality.com/2015/12/babel6-loose-mode.html).


⚠️

These [assumptions](https://babeljs.io/docs/assumptions) are made in loose mode by default, you might get unexpected reault if your code doesn't meet these assumptions.
- [privateFieldsAsProperties](https://babeljs.io/docs/assumptions#privatefieldsasproperties)
- [setPublicClassFields](https://babeljs.io/docs/assumptions#setpublicclassfields)
- [constantSuper](https://babeljs.io/docs/assumptions#constantsuper)
- [noDocumentAll](https://babeljs.io/docs/assumptions#nodocumentall)
- [pureGetters](https://babeljs.io/docs/assumptions#puregetters)
- [objectRestNoSymbols](https://babeljs.io/docs/assumptions#objectrestnosymbols)
- [setSpreadProperties](https://babeljs.io/docs/assumptions#setspreadproperties)
- ignoreFunctionName
- [ignoreFunctionLength](https://babeljs.io/docs/assumptions#ignorefunctionlength)
- [ignoreToPrimitiveHint](https://babeljs.io/docs/assumptions#ignoretoprimitivehint)
- [mutableTemplateObject](https://babeljs.io/docs/assumptions#mutabletemplateobject)
- [noClassCalls](https://babeljs.io/docs/assumptions#noclasscalls)
- [setClassMethods](https://babeljs.io/docs/assumptions#setclassmethods)
- [superIsCallableConstructor](https://babeljs.io/docs/assumptions#superiscallableconstructor)
- [iterableIsArray](https://babeljs.io/docs/assumptions#iterableisarray)

```json title=".swcrc"
{
  "jsc": {
    "loose": true
  }
}
```

## jsc.transform

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "react": {
        "pragma": "React.createElement",
        "pragmaFrag": "React.Fragment",
        "throwIfNamespace": true,
        "development": false,
        "useBuiltins": false
      },
      "optimizer": {
        "globals": {
          "vars": {
            "__DEBUG__": "true"
          }
        }
      }
    }
  }
}
```

### jsc.transform.legacyDecorator

You can use the legacy (stage 1) class decorators syntax and behavior.

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "decorators": true
    },
    "transform": {
      "legacyDecorator": true
    }
  }
}
```

### jsc.transform.decoratorMetadata

This feature requires `v1.2.13+`.

If you are using typescript and decorators with `emitDecoratorMetadata` enabled, you can use `swc` for faster iteration:

```json title=".swcrc"
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "decorators": true
    },
    "transform": {
      "legacyDecorator": true,
      "decoratorMetadata": true
    }
  }
}
```

### jsc.transform.react

#### jsc.transform.react.runtime

Possible values: `automatic`, `classic`, `preserve`.

Decides which runtime to use when transforming JSX.

- Defaults to `'classic'`.
- Use `runtime: 'automatic'` to use a JSX runtime module (e.g. `react/jsx-runtime` introduced in React 17). This is the modern approach introduced in React 17+ that eliminates the need to manually import React in every file that uses JSX.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "react": {
        "runtime": "automatic"
      }
    }
  }
}
```

- Use `runtime: 'classic'` to use the traditional JSX transform that relies on `React.createElement` calls - with this option, you must ensure that `React` is in scope when using JSX.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "react": {
        "runtime": "classic"
      }
    }
  }
}
```

- Use `runtime: 'preserve'` to leave JSX syntax unchanged without transforming it.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "react": {
        "runtime": "preserve"
      }
    }
  }
}
```

[Learn more here](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html).

#### jsc.transform.react.importSource

- Defaults to `react`.
- When using `runtime: automatic`, determines the runtime library to import.
- This option can be overrided with `@jsxImportSource foo`.

#### jsc.transform.react.pragma

- Defaults to `React.createElement`.
- When using `runtime: classic`, replaces the function used when compiling JSX expressions.
- This option can be overrided with `@jsx foo`.

#### jsc.transform.react.pragmaFrag

- Defaults to `React.Fragment`
- Replace the component used when compiling JSX fragments.
- This option can be overrided with `@jsxFrag foo`.

#### jsc.transform.react.throwIfNamespace

Toggles whether or not to throw an error if an XML namespaced tag name is used. For example: `<f:image />`

Though the JSX spec allows this, it is disabled by default since React's JSX does not currently have support for it.

#### jsc.transform.react.development

Toggles debug props `__self` and `__source` on elements generated from JSX, which are used by development tooling such as React Developer Tools.

This option is set automatically based on the Webpack `mode` setting when used with `swc-loader`. See [Using swc with webpack](/docs/usage/swc-loader.md).

#### jsc.transform.react.useBuiltins

Use `Object.assign()` instead of `_extends`. Defaults to false.

#### jsc.transform.react.refresh

Enable [react-refresh](https://www.npmjs.com/package/react-refresh) related transform. Defaults to `false` as it's considered experimental.

Pass `refresh: true` to enable this feature, or an object with the following:

```ts
interface ReactRefreshConfig {
  refreshReg: String;
  refreshSig: String;
  emitFullSignatures: boolean;
}
```

### jsc.transform.constModules

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "constModules": {
        "globals": {
          "@ember/env-flags": {
            "DEBUG": "true"
          },
          "@ember/features": {
            "FEATURE_A": "false",
            "FEATURE_B": "true"
          }
        }
      }
    }
  }
}
```

Then, source code like:

```js title="source.js"
import { DEBUG } from "@ember/env-flags";
import { FEATURE_A, FEATURE_B } from "@ember/features";

console.log(DEBUG, FEATURE_A, FEATURE_B);
```

is transformed to:

```js title="output.js"
console.log(true, false, true);
```

### jsc.transform.optimizer

The SWC optimizier assumes:

- It's a module or wrapped in an iife.
- Accessing (get) global variables does not have a side-effect. It is the same assumption as the google closure compiler.
- You don't add fields to literals like a numeric literal, regular expression or a string literal.
- Files are served as gzipped.

SWC will not focus on reducing the size of non-gzipped file size.

Setting this to `undefined` skips optimizer pass.

#### jsc.transform.optimizer.simplify

> Requires `v1.2.101+`

You can set this to `false` to use `inline_globals` while skipping optimizations.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "optimizer": {
        "simplify": false,
        "globals": {
          "vars": {
            "__DEBUG__": "true"
          }
        }
      }
    }
  }
}
```

#### jsc.transform.optimizer.globals

> Requires `v1.2.101+`

- `vars` - Variables to inline.
- `typeofs` - If you set `{ "window": "object" }`, `typeof window` will be replaced with `"object"`.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "optimizer": {
        "globals": {
          "vars": {
            "__DEBUG__": "true"
          }
        }
      }
    }
  }
}
```

Then, you can use it like `npx swc '__DEBUG__' --filename input.js`.

#### jsc.transform.optimizer.jsonify

> Requires `v1.1.1+`

- `minCost` - If cost of parsing a pure object literal is larger than this value, the object literal is converted to `JSON.parse('{"foo": "bar"}')`. Defaults to 1024.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "optimizer": {
        "jsonify": {
          "minCost": 0
        }
      }
    }
  }
}
```

This will change all **pure** object literals to `JSON.parse("")`.

## jsc.keepClassNames

> Requires `v1.2.50+` and target to be es2016 or higher

Enabling this option will make swc preserve original class names.

## jsc.paths

> Requires `v1.2.62+`

Syntax is identical as it of `tsconfig.json`: [learn more](https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping).

Requires `jsc.baseUrl`. See below.

## jsc.baseUrl

The path must be specified as an absolute path.

[Learn more](https://www.typescriptlang.org/docs/handbook/module-resolution.html#base-url).

## jsc.minify

> Requires `v1.2.67+`

See [the documentation for minification](/docs/configuration/minification.md) for more details.

## jsc.experimental

### jsc.experimental.keepImportAttributes

Preserve import attributes.
This is experimental because import attributes are not covered by ecmascript specifications yet.

### jsc.experimental.plugins

It follows resolving rule of node.js,.

Specify the plugin name like

```json title=".swcrc"
{
  "jsc": {
    "experimental": {
      "plugins": [
        ["@swc/plugin-styled-jsx", {}]
      ]
    }
  }
}
```

`styled-jsx` works because it's published as `@swc/plugin-styled-jsx`.

### jsc.experimental.cacheRoot

Specify the location where SWC stores its intermediate cache files.

Currently only transform plugin uses this. If not specified, SWC will create `.swc` directories.

```json title=".swcrc"
{
  "jsc": {
    "experimental": {
      "cacheRoot": "node_modules/.cache/swc"
    }
  }
}
```

## jsc.preserveAllComments

Indicate that all comments should be preserved during compilation. Comments from source may be shifted in order to preserve thier relative location from source
to compiled output.
This feature is useful for transpilation that requires comments remain relatively close to the source: e.g. files under test with istanbul-ignore coverage
annotations.

## jsc.transform.useDefineForClassFields

Possilbe values:

- `true`:

```js
class Foo {
  init = 3;
}

console.log(Foo.init)
```

will be compiled as

```js
class Foo {
    constructor(){
        // Helper
        _defineProperty(this, "init", 3);
    }
}
console.log(Foo.init);
```

- `false`:

```js
class Foo {
  init = 3;
}

console.log(Foo.init)
```

will be compiled as

```js
class Foo {
    constructor(){
        this.init = 3;
    }
}
console.log(Foo.init);
```

## jsc.transform.decoratorVersion

Starting from `v1.3.47`, you can use stage 3 decorator.

```json title=".swcrc"
{
    "jsc": {
        "parser": {
            "syntax": "ecmascript",
            "decorators": true
        },
        "transform": {
            "decoratorVersion": "2022-03"
        }
    }
}
```

Possible values:

- `"2021-12"` (default)

Legacy decorator.

- `"2022-03"`

Initial Stage 3 decorator.

- `"2023-11"`

TC39 decorator with proposal updates as of November 2023.

### jsc.output

#### jsc.output.charset

Possible values: `utf8`, `ascii`.

This can be used to keep the output ascii-only.

## Multiple Entries

> Requires `v1.0.47+`

```json
[
  {
    "test": ".*\\.js$",
    "module": {
      "type": "commonjs"
    }
  },
  {
    "test": ".*\\.ts$",
    "module": {
      "type": "amd"
    }
  }
]
```

This makes SWC compile JavaScript files as CommonJS modules and compile TypeScript files as AMD modules.

Note that `test` option can be used to transcompile only typescript files, like

```json title=".swcrc"
{
  "test": ".*\\.ts$",
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": true,
      "dynamicImport": true
    }
  }
}
```

## test

Type: `Regex / Regex[]`

```json title=".swcrc"
{
  "test": ".*\\.ts$",
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": true,
      "dynamicImport": true
    }
  }
}
```

## exclude

Type: `Regex / Regex[]`

```json title=".swcrc"
{
  "exclude": [".*\\.js$", ".*\\.map$"],
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": true,
      "dynamicImport": true
    }
  }
}
```

## sourceMaps

> Requires `v1.2.50+`

Enable source map by adding `sourceMaps: true` or `sourceMaps: 'inline'` to the `.swcrc`.

```json title=".swcrc"
{
  "sourceMaps": true
}
```

## inlineSourcesContent

> Requires `v1.2.101+`

Defaults to `true`. If you want to make `swc` store contents of files into sourcemap, you can set `inlineSourcesContent` to `true`.

```json title=".swcrc"
{
  "sourceMaps": true,
  "inlineSourcesContent": true
}
```

## isModule

Possible values: `true`, `false`, `"unknown"`

Used to treat input as a module or script.
If this is set to `unknown`, it will be `Module` if it's esm and `Script` otherwise.



---
url: /docs/configuration/react-compiler.md
---

# React Compiler

> Requires `@swc/core` v1.15.43 or later.

SWC includes a native implementation of the React Compiler transform. Enable it
with `jsc.transform.reactCompiler`. The transform runs before SWC transforms
JSX, so it works with the existing `jsc.transform.react` configuration.

## Getting started

Set `reactCompiler` to `true` to use the default configuration:

```json title=".swcrc"
{
  "$schema": "https://swc.rs/schema.json",
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": true
    },
    "transform": {
      "reactCompiler": true,
      "react": {
        "runtime": "automatic"
      }
    }
  }
}
```

The same configuration can be passed to the `transform` and `transformSync`
APIs:

```ts
import { transformSync } from "@swc/core";

const output = transformSync(source, {
  jsc: {
    parser: {
      syntax: "typescript",
      tsx: true,
    },
    transform: {
      reactCompiler: true,
      react: {
        runtime: "automatic",
      },
    },
  },
});
```

Set `reactCompiler` to `false` or omit it to disable the transform.

## Runtime target

The compiled output imports a memoization runtime. Select the runtime that
matches the React version used by the application:

| `target`         | Runtime import           | Setup                                                          |
| ---------------- | ------------------------ | -------------------------------------------------------------- |
| `"19"` (default) | `react/compiler-runtime` | Provided by React 19.                                          |
| `"17"` or `"18"` | `react-compiler-runtime` | Install `react-compiler-runtime` as an application dependency. |

For example, a React 18 application can use:

```sh
pnpm add react-compiler-runtime
```

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "reactCompiler": {
        "target": "18"
      }
    }
  }
}
```

## Options

Pass an object instead of `true` to override individual compiler options.
Unspecified fields retain their defaults.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "reactCompiler": {
        "compilationMode": "infer",
        "panicThreshold": "none",
        "target": "19",
        "outputMode": "client",
        "isDev": false
      }
    }
  }
}
```

### compilationMode

Type: `"infer" | "syntax" | "annotation" | "all"`

Default: `"infer"`

Controls which functions the compiler attempts to compile:

- `"infer"` identifies React components and hooks using naming and code
  conventions.
- `"syntax"` compiles declared component and hook syntax, as well as functions
  with an opt-in directive.
- `"annotation"` compiles only functions with an opt-in directive such as
  `"use memo"`.
- `"all"` attempts to compile every function.

### panicThreshold

Type: `"none" | "critical_errors" | "all_errors"`

Default: `"none"`

Controls which compiler errors stop the transform. With the default value,
functions that cannot be compiled are left unchanged instead of failing the
transform.

### target

Type: `"17" | "18" | "19"`

Default: `"19"`

Selects the React runtime version. See [Runtime target](#runtime-target) for the
corresponding runtime dependency.

### noEmit

Type: `boolean`

Default: `false`

Analyzes the source and reports diagnostics without emitting React Compiler
transformations. This also selects lint output behavior.

### outputMode

Type: `"client" | "ssr" | "lint"`

Default: `"client"`

Selects client, server-side rendering, or lint output behavior. `noEmit: true`
also uses lint output behavior.

### ignoreUseNoForget

Type: `boolean`

Default: `false`

Compiles functions even when they contain a standard opt-out directive such as
`"use no memo"` or `"use no forget"`.

### flowSuppressions

Type: `boolean`

Default: `true`

Treats matching Flow suppression comments as opt-outs from compilation.

### enableReanimated

Type: `boolean`

Default: `false`

Enables compatibility with `react-native-reanimated` worklets.

### isDev

Type: `boolean`

Default: `false`

Enables development-mode compiler output.

### eslintSuppressionRules

Type: `string[]`

Specifies ESLint rule names whose suppression comments opt a function out of
compilation.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "reactCompiler": {
        "eslintSuppressionRules": ["react-hooks/exhaustive-deps"]
      }
    }
  }
}
```

### customOptOutDirectives

Type: `string[]`

Replaces the standard opt-out directives with a custom list of function
directives that opt out of compilation.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "reactCompiler": {
        "customOptOutDirectives": ["use no optimize"]
      }
    }
  }
}
```

### gating

Type: `{ source: string; importSpecifierName: string }`

Emits both the original and compiled functions and selects between them by
calling an imported gating function.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "reactCompiler": {
        "gating": {
          "source": "./feature-flags",
          "importSpecifierName": "isReactCompilerEnabled"
        }
      }
    }
  }
}
```

This configuration imports `isReactCompilerEnabled` from `./feature-flags` and
uses its return value to choose the compiled or original function.

### dynamicGating

Type: `{ source: string }`

Enables per-function gating with a `"use memo if(identifier)"` directive. The
identifier is imported from `source` and called as the gate for that function.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "reactCompiler": {
        "dynamicGating": {
          "source": "./feature-flags"
        }
      }
    }
  }
}
```

```tsx title="component.tsx"
export function FilteredList() {
  "use memo if(isFilteredListCompilerEnabled)";
  // ...
}
```

### environment.enableFunctionOutlining

Type: `boolean`

Default: `true`

> Requires `@swc/core` v1.15.47 or later.

Controls whether anonymous functions that do not capture local variables are
extracted into top-level helper functions. The `environment` object currently
exposes only this option.

```json title=".swcrc"
{
  "jsc": {
    "transform": {
      "reactCompiler": {
        "environment": {
          "enableFunctionOutlining": false
        }
      }
    }
  }
}
```



---
url: /docs/configuration/supported-browsers.md
---

# Supported Browsers

Starting with `v1.1.10`, you can now use `browserslist` to automatically configure supported browsers.

## Usage

```json title=".swcrc"
{
  "env": {
    "targets": {
      "chrome": "79"
    },
    "mode": "entry",
    "coreJs": "3.22"
  }
}
```

## Options

### targets

`string | Array<string> | { [string]: string }`, defaults to `{}`.

Describes the environments you support/target for your project. This can either be a [browserslist-compatible](https://github.com/ai/browserslist) query [(with limitations)](https://github.com/browserslist/browserslist-rs#limitations):

```json title=".swcrc"
{
  "env": {
    "targets": "> 0.25%, not dead"
  }
}
```

Or an object of minimum environment versions to support:

```json title=".swcrc"
{
  "env": {
    "targets": {
      "chrome": "58",
      "ie": "11"
    }
  }
}
```

Example environments:

- `chrome`
- `opera`
- `edge`
- `firefox`
- `safari`
- `ie`
- `ios`
- `android`
- `node`
- `electron`

If `targets` is not specified, SWC uses `browserslist` to get target information.

### path

- `string`, defaults to current directory.
- `path` specifies the directory to load the `browserslist` module and any browserslist configuration files. For example, `.browserslistrc` or `browserslist` field in package.json. This can be useful if your build system isn't in the root of your project.

### mode

- `string`, defaults to `undefined`.
- Possible values: `usage`, `entry`, `undefined` (this matches [`useBuiltIns`](https://babeljs.io/docs/en/babel-preset-env#usebuiltins) from Babel)


⚠️

The <code>usage</code> mode is currently not as efficient as Babel, iff you have a usage like `"foo"["a" + "t"]()`.
SWC does not evaluate the expression <code>"a" + "t"</code> and will not include the <code>String.prototype.at</code> polyfill.

### skip

Define ES features to skip to reduce bundle size. For example, your `.swcrc` could be:

```json title=".swcrc"
{
  "env": {
    "skip": ["core-js/modules/foo"]
  }
}
```

### coreJs

- `string`, defaults to `undefined`.
- `coreJs` specifies the version of `core-js` to use, can be any core-js versions supported by swc. E.g., `"3.22"`.

The option has an effect when used alongside `mode: "usage"` or `mode: "entry"`. It is recommended to specify the minor version (E.g. `"3.22"`) otherwise `"3"` will be interpreted as `"3.0"` which may not include polyfills for the latest features.

When `coreJs` is `undefined`, SWC falls back to `core-js@3.0.0`.

## Additional Options

- `debug`: (_boolean_) defaults to `false`.
- `dynamicImport`: (_boolean_) defaults to `false`.
- `loose`: (_boolean_) defaults to `false`. Enable [loose transformations](http://2ality.com/2015/12/babel6-loose-mode.html) for any plugins that allow them.
- `include`: (_string\[]_) can be a `core-js` module (`es.math.sign`) or an SWC pass (`transform-spread`).
- `exclude`: (_string\[]_) can be a `core-js` module (`es.math.sign`) or an SWC pass (`transform-spread`).
- `shippedProposals`: (_boolean_) defaults to `false`.
- `forceAllTransforms`: (_boolean_) defaults to `false`. Enable all possible transforms.



---
url: /docs/configuration/modules.md
---

💡

SWC provides an official JSON Schema for the configuration file.
```json title=".swcrc"
{
  "$schema": "https://swc.rs/schema.json",
}
```

# Modules

SWC can transpile your code using ES Modules to CommonJS or UMD/AMD. By default, module statements will remain untouched.

## CommonJS

To emit a CommonJS module, change the `type` in `.swcrc`:

```json title=".swcrc"
{
  "$schema": "https://swc.rs/schema.json",
  "module": {
    "type": "commonjs",

    // These are defaults.
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false
  }
}
```

## ES6

To emit a ES6 module, change the `type` in `.swcrc`:

```json title=".swcrc"
{
  "module": {
    "type": "es6",

    // These are defaults.
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false
  }
}
```

## AMD

To emit an AMD module, change the `type` in `.swcrc`:

```json title=".swcrc"
{
  "module": {
    "type": "amd",
    // Optional. If specified, swc emits named AMD module.
    "moduleId": "foo",

    // These are defaults.
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false
  }
}
```

## UMD

To emit an UMD module, change the `type` in `.swcrc`:

```json title=".swcrc"
{
  "module": {
    "type": "umd",
    "globals": {},

    // These are defaults.
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false
  }
}
```

## Shared Options

These options are shared by `commonjs` / `es6` / `umd` / `amd` inside `.swcrc`:

```json title=".swcrc"
{
  "module": {
    // You can specify "commonjs", "es6", "amd", "umd"
    "type": "commonjs",
    "strict": false,
    "strictMode": true,
    "lazy": false,
    "noInterop": false,
    "ignoreDynamic": false,
    "preserveImportMeta": false,
    "outFileExtension": "js",
  }
}
```

### strict

Defaults to `false`. By default, when using exports with SWC, a non-enumerable `__esModule` property is exported. In some cases, this property is used to determine if the import is the default export or if it contains the default export.

To prevent the `__esModule` property from being exported, you can set the strict option to `true`.

### strictMode

Defaults to `true`. If true, swc emits 'use strict' directive.

### lazy

Defaults to `false`. This option changes Babel's compiled `import` statements to be lazily evaluated when their imported bindings are used for the first time. This can improve the initial load time of your module because evaluating dependencies upfront is sometimes entirely unnecessary. This is especially the case when implementing a library module.

The value of `lazy` has a few possible effects:

- `false` - No lazy initialization of any imported module.
- `true` - Do not lazy-initialize local `./foo` imports, but lazy-init `foo` dependencies. Local paths are much more likely to have circular dependencies, which may break if loaded lazily, so they are not lazy by default, whereas dependencies between independent modules are rarely cyclical.
- `Array<string>` - Lazy-initialize all imports with source matching one of the given strings.

The two cases where imports can never be lazy are:

- `import "foo";`
  Side-effect imports are automatically non-lazy since their very existence means that there is no binding to later kick-off initialization.
- `export from "foo"`
  Re-exporting all names requires up-front execution because otherwise there is no
  way to know what names need to be exported.

### noInterop

Defaults to `false`. By default, when using exports with swc a non-enumerable `__esModule` property is exported.
This property is then used to determine if the import is the default export or if it contains the default export.

In cases where the auto-unwrapping of default is not needed, you can set the noInterop option to true to avoid the usage of the interopRequireDefault helper (shown in inline form above).

### ignoreDynamic

If set to `true`, dynamic imports will be preserved.

### preserveImportMeta

If set to `true`, `import.meta` will be preserved.

### importInterop

Possible values:

- `swc` (alias: `babel`)
- `node`
- `none`

Defaults to `none` if `noInterop` is true, and `swc` otherwise.

### resolveFully

When set to `true`, fully resolves module `import` file paths, including any that end with `index.js`.

### outFileExtension

when supplied with `resolveFully`, this will change the extension of any locally resolved file paths to
be the one specified. You should use this extension to match the `--out-file-extension` option for @swc/cli.



---
url: /docs/configuration/minification.md
---

# Minification


⚠️

This section is for people who want to use swc as a last step of the build process.
If you want to use the swc minifier with a bundler, see the documentation for
- [swcMinify with the Terser Webpack Plugin](https://webpack.js.org/plugins/terser-webpack-plugin/#swc)
- [SWC Minify Webpack Plugin](https://www.npmjs.com/package/swc-minify-webpack-plugin) which is a standalone tool if you only want minification.

# Assumptions

SWC Minifier makes small amount of assumptions to make the minification efficient. This is similar to other minifiers.

- `.toString()` and `.valueOf()` don't have side effects, and for built-in objects they have not been overridden.

- `undefined`, `NaN` and `Infinity` have not been externally redefined.

- `arguments.callee`, `arguments.caller` and `Function.prototype.caller` are not used.

These are not valid in strict mode.

- The code doesn't expect the contents of `Function.prototype.toString()` or `Error.prototype.stack` to be anything in particular.

- Getting and setting properties on a plain object does not cause other side effects (using `.watch()` or `Proxy`).

- Object properties can be added, removed and modified (not prevented with `Object.defineProperty()`, `Object.defineProperties()`, `Object.freeze()`, `Object.preventExtensions()` or `Object.seal()`).

- `document.all` is not `null`.

- Assigning properties to a class doesn't have side effects and does not throw.

- Acesssing **declared** top-level identifiers do not have side effects.

If you declare a variable on `globalThis` using a getter with side-effects, SWC Minifier will likely break it.

- TDZ violation does not exist.

TDZ violation will be ignored and not preserved.

- Arithmetic expression may **not** have side effects.

This assumption means that you can't rely on the exception thrown by the JS engine when adding a bigint and a number.

```ts
const a = 1n;
const b = 1;
const c = a + b;
```

If you execute this code, the JS engine will throw an exception. But SWC Minifier will ignore it.

Related: [terser - compiler assumptions](https://github.com/terser/terser#compiler-assumptions)

***

Starting with `v1.2.67`, you can configure SWC to minify your code by enabling `minify` in your `.swcrc` file:

```json title=".swcrc"
{
  // Enable minification
  "minify": true,
  // Optional, configure minification options
  "jsc": {
    "minify": {
      "compress": {
        "unused": true
      },
      "mangle": true
    }
  }
}
```

## Configuration

### Note about comments

If you set `jsc.minify.compress` to `true` or `{}`, SWC will remove all comments starting from `v1.11.11`.
Previous versions will preserve only license comments.
If you don't want this, modify `jsc.minify.format`.

### `jsc.minify.compress`

Type: `boolean | object`.

Similar to [the compress option](https://terser.org/docs/options/#compress-options) of `terser`.

```json title=".swcrc"
{
  "jsc": {
    "minify": {
      "compress": true // equivalent to {}
    }
  }
}
```

- `arguments`, defaults to `false`.
- `arrows`, defaults to `true`.
- `booleans`, defaults to `true`.
- `booleans_as_integers`, defaults to `false`.
- `collapse_vars`, defaults to `true`.
- `comparisons`, defaults to `true`.
- `computed_props`, defaults to `true`.
- `conditionals`, defaults to `true`.
- `dead_code`, defaults to `true`.
- `defaults`, defaults to `true`.
- `directives`, defaults to `true`.
- `drop_console`, defaults to `false`.
- `drop_debugger`, defaults to `true`.
- `ecma`, defaults to `5`.
- `evaluate`, defaults to `true`.
- `global_defs`, defaults to `{}`.
- `hoist_funs`, defaults to `false`.
- `hoist_props`, defaults to `true`.
- `hoist_vars`, defaults to `false`.
- `ie8`, Ignored.
- `if_return`, defaults to `true`.
- `inline`, defaults to `true`.
- `join_vars`, defaults to `true`.
- `keep_classnames`, defaults to `false`.
- `keep_fargs`, defaults to `false`.
- `keep_infinity`, defaults to `false`.
- `loops`, defaults to `true`.
- `negate_iife`, defaults to `true`.
- `passes`, defaults to `0`, which means no limit.
- `properties`, defaults to `true`.
- `pure_getters`, defaults to \`\`.
- `pure_funcs`, defaults to `[]`. Type is an array of string.
- `reduce_funcs`, defaults to `false`.
- `reduce_vars`, defaults to `true`.
- `sequences`, defaults to `true`.
- `side_effects`, defaults to `true`.
- `switches`, defaults to `true`.
- `top_retain`, defaults to \`\`.
- `toplevel`, defaults to `true`.
- `typeofs`, defaults to `true`.
- `unsafe`, defaults to `false`.
- `unsafe_arrows`, defaults to `false`.
- `unsafe_comps`, defaults to `false`.
- `unsafe_Function`, defaults to `false`.
- `unsafe_math`, defaults to `false`.
- `unsafe_symbols`, defaults to `false`.
- `unsafe_methods`, defaults to `false`.
- `unsafe_proto`, defaults to `false`.
- `unsafe_regexp`, defaults to `false`.
- `unsafe_undefined`, defaults to `false`.
- `unused`, defaults to `true`.
- `module`, Ignored. Currently, all files are treated as module.

### `jsc.minify.mangle`

Type: `boolean | object`.

Similar to [the mangle option](https://terser.org/docs/options/#mangle-options) of `terser`.

```json title=".swcrc"
{
  "jsc": {
    "minify": {
      "mangle": true // equivalent to {}
    }
  }
}
```

- `props`, Defaults to `false`, and `true` is identical to `{}`.
- `topLevel`, Defaults to `true`. Aliased as `toplevel` for compatibility with `terser`.
- `keepClassNames`, Defaults to `false`. Aliased as `keep_classnames` for compatibility with `terser`.
- `keepFnNames`, Defaults to `false`.
- `keepPrivateProps`, Defaults to `false`. Aliased as `keep_private_props` for compatibility with `terser`.
- `reserved`, Defaults to `[]`
- `ie8`, Ignored.
- `safari10`, Defaults to `false`.

#### `jsc.minify.mangle.properties`

Type: `object`.

Similar to [the mangle properties option](https://terser.org/docs/options/#mangle-properties-options) of `terser`.

```json title=".swcrc"
{
  "jsc": {
    "minify": {
      "mangle": {
        "properties": {
          "reserved": ["foo", "bar"],
          "undeclared": false,
          "regex": "rust regex"
        }
      }
    }
  }
}
```

- `reserved`: Don't use these names as properties.

- `undeclared`: Mangle properties even if it's not declared.

- `regex`: Mangle properties only if it matches this regex

### `jsc.minify.format`

These properties are mostly not implemented yet, but it exists to support passing terser config to swc minify without modification.

- `asciiOnly`, Defaults to `false`. Implemented as `v1.2.184` and aliased as `ascii_only` for compatibility with `terser`.
- `beautify`, Defaults to `false`. Currently noop.
- `braces`, Defaults to `false`. Currently noop.
- `comments`, Defaults to `some`.
  - `false` removes all comments
  - `'some'` preserves some comments
  - `'all'` preserves all comments
- `ecma`, Defaults to 5. Currently noop.
- `indentLevel`, Currently noop and aliases as `indent_level` for compatibility with `terser`.
- `indentStart`, Currently noop and aliases as `indent_start` for compatibility with `terser`.
- `inlineScript`, Aliases as `inline_script` for compatibility with `terser` and requires `@swc/core@1.9.2` or later.
- `keepNumbers`, Currently noop and aliases as `keep_numbers` for compatibility with `terser`.
- `keepQuotedProps`, Currently noop and aliases as `keep_quoted_props` for compatibility with `terser`.
- `maxLineLen`, Currently noop, and aliases as `max_line_len` for compatibility with `terser`.
- `preamble`, Supported since `v1.3.66`.
- `quoteKeys`, Currently noop and aliases as `quote_keys` for compatibility with `terser`.
- `quoteStyle`, Currently noop and aliases as `quote_style` for compatibility with `terser`.
- `preserveAnnotations`, Currently noop and aliases as `preserve_annotations` for compatibility with `terser`.
- `safari10`, Currently noop.
- `semicolons`, Currently noop.
- `shebang`, Currently noop.
- `webkit`, Currently noop.
- `wrapIife`, Currently noop and aliases as `wrap_iife` for compatibility with `terser`.
- `wrapFuncArgs`, Currently noop and aliases as `wrap_func_args` for compatibility with `terser`.

## @swc/core Usage

### swc.minify(code, options)

This API is asynchronous and all of parsing, minification, and code generation will be done in background thread. The `options` argument is same as `jsc.minify` object. For example:

```js
import swc from "@swc/core";

const { code, map } = await swc.minify(
  "import foo from '@src/app'; console.log(foo)",
  {
    compress: false,
    mangle: true,
  }
);

expect(code).toMatchInlineSnapshot(`"import a from'@src/app';console.log(a);"`);
```

Returns `Promise<{ code: string, map: string }>`.

### swc.minifySync(code, options)

This API exists on `@swc/core`, `@swc/wasm`, `@swc/wasm-web`.

```js
import swc from "@swc/core";

const { code, map } = swc.minifySync(
  "import foo from '@src/app'; console.log(foo)",
  {
    compress: false,
    mangle: true,
    module: true,
  }
);

expect(code).toMatchInlineSnapshot(`"import a from'@src/app';console.log(a);"`);
```

Returns `{ code: string, map: string }`.

## APIs for WebAssembly

### Replacing Terser

You can reduce build time and override Terser without needing a library to update their dependencies through [yarn resolutions](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/). Example `package.json` would include:

```json title="package.json"
{
  "resolutions": { "terser": "npm:@swc/core" }
}
```

This will use the SWC minifier instead of Terser for all nested dependencies. Ensure you remove your lockfile and re-install your dependencies.

```sh
$ rm -rf node_modules yarn.lock
$ yarn
```



---
url: /docs/configuration/bundling.md
---

# Bundling Configuration


🚧

This feature will be dropped in v2, in favor of SWC-based bundlers like [Parcel 2](https://parceljs.org/), [Turbopack](https://turbo.build/pack/docs), [Rspack](https://rspack.rs/), [fe-farm](https://www.farmfe.org/).
Please use one of the bundlers instead.

SWC is able to bundle multiple JavaScript or TypeScript files into one.

This feature is currently named `spack`, but will be renamed to `swcpack` in `v2`. `spack.config.js` will be deprecated for `swcpack.config.js`.

View a [basic example of bundling](https://github.com/swc-project/pkgs/tree/main/packages/cli/examples/spack-basic).

## Configuration

You can configure bundling using `spack.config.js` with similar options to webpack. In the future, we are exploring a webpack compatible plugin system.

```js title="spack.config.js"

module.exports = {
  entry: {
    web: __dirname + "/src/index.ts",
  },
  output: {
    path: __dirname + "/lib",
  },
};
```

> Note: CommonJS is currently required. In the future, ES Modules will be supported.

If you want auto-completion or type checking for configuration, you can wrap the export with a `config` function from `@swc/core/spack`. It's an identity function with type annotation.

```ts title="spack.config.js"
const { config } = require("@swc/core/spack");

module.exports = config({
  entry: {
    web: __dirname + "/src/index.ts",
  },
  output: {
    path: __dirname + "/lib",
  },
});
```

### mode

Possible values: `production`, `debug`, `none`.

Currently this value is not used, but it will behave similarly to webpack.

### entry

Determines the entry of bundling. You may specify a file or a map of bundle name to file path.

> Note: Currently this should be absolute path. You can use `__dirname` to create one.
>
> In the future, SWC will support using relative paths and will resolve files relative to `spack.config.js`.

### output

You can change destination directory of the bundler using `output`.

```ts title="spack.config.js"
const { config } = require("@swc/core/spack");

module.exports = config({
  output: {
    path: __dirname + "/lib",
    // Name is optional.
    name: "index.js",
  },
});
```

### options

Used to control the behavior of SWC. This field is optional.



---
url: /docs/plugin/selecting-swc-core.md
---

# Selecting the version

Currently, the Wasm plugins are not backwards compatible.
So you need to select an appropriate version of `swc_core` for your plugin.

We provide a simple webapp to help you select the version of `swc_core`.

See: [https://plugins.swc.rs](https://plugins.swc.rs)

You can select the framework and the version of **framework** you are using, and the Wasm plugins compatible with it will be shown.

# OLD Documentation for the version of `swc_core`

Please use the webapp instead.

The page documents the version of `swc_core` you can use for each runtime.

## Note for next.js

- [next `v13.2.4` \~ `v13.3.1` cannot execute SWC Wasm plugins, due to a bug of `next-swc`](https://github.com/vercel/next.js/issues/46989#issuecomment-1486989081).

## swc\_core

If you use a version in a range of the title, the Wasm plugin will work for the runtimes written in the body.

### `v0.98.x` \~

#### Changes

- `Span.ctxt` is removed to reduce the size of `Span`.
- `ctxt: SyntaxContext` is added to various AST nodes.
- `IdentName` is used instead of `Ident` in some places like `MemberProp`, because those fields does not need `ctxt` or `optional`.

#### Upgrade guide

- The update PR for the official plugins: [plugins#334](https://github.com/swc-project/plugins/pull/334)

#### Versions

- `@swc/core@1.7.x`
- `next@v15.0.0-canary.117` (reverted in `next@v15.0.0-canary.118`)
- `next@v15.0.0-canary.122` \~

### `v0.95.x` \~ `v0.96.x`

- [CHANGELOG](https://github.com/swc-project/swc/blob/064af5391d8da9599f277bd68fd0b479b0b1235c/CHANGELOG.md#160---2024-06-15)

We optimized some AST type definitions.

- `@swc/core@1.6.x`
- `next@15.0.0-canary.37` \~ `next@v15.0.0-canary.116`

### `v0.94.x`

Do not use this version if you are building a plugin for SWC.

### `v0.91.x` \~ `v0.93.x`

We added support for abstract auto-accessors.

- `@swc/core@1.5.x`
- `next@15.0.0-canary.29` \~ `v15.0.0-canary.36`

### `v0.90.x`

We refactored AST to make it less error-prone.

- `@swc/core@1.4.x`
- `next@14.1.1-canary.52` \~ `next@15.0.0-canary.28`
- `@rspack/core@0.6.0` \~

### `v0.88.x` \~ `v0.89.x`

Support for import phase proposal (stage 3) was added.

- `@swc/core@1.3.106` \~ `@swc/core@1.3.107`
- `@rspack/core@0.5.8` \~ `@rspack/core@0.5.9`

### `v0.82.x` \~ `v0.87.x`

We modified AST definitions because of `with` of [Import Attributes proposal](https://github.com/tc39/proposal-import-attributes).

- `@swc/core@1.3.81` \~ `@swc/core@1.3.105`
- \~ `next@14.1.0`

Note: You may need to specify the version of `swc_common`, too, like

```toml
[dependencies]
swc_common = "=0.33.15"
```

### `v0.79.x` \~ `v0.81.x`

We modified AST definitions because of `await` of [Explicit Resource Management proposal](https://github.com/tc39/proposal-explicit-resource-management).

- `@swc/core@1.3.68` \~ `@swc/core@1.3.80`
- `next@13.4.10-canary.1` \~

### `v0.78.x`

We modified AST definitions because some of the previous definitions were misdesigned.

- `@swc/core@1.3.63` \~ `@swc/core@1.3.67`
- `next@13.4.8` \~ `next@13.4.10-canary.0`

### `v0.76.x` \~ `v0.77.x`

We modified AST definitions because of [Explicit Resource Management proposal](https://github.com/tc39/proposal-explicit-resource-management), which is stage 3.

- `@swc/core@1.3.58` \~ `@swc/core@1.3.62`
- `next@13.4.3-canary.2` \~ `next@13.4.7`

### `v0.75.x`

We enabled strict mode of `rkyv` and updated `wasmer` to `v3`.

- `@swc/core@1.3.49` \~ `@swc/core@1.3.57`
- `v13.3.1-canary.12` \~ `next@13.4.3-canary.1`

### `v0.72.4` \~ `v0.74.6`

We updated `rkyv` to `v0.7.40` and the bug is now fixed.

- `@swc/core@1.3.44` \~ `@swc/core@1.3.47`

### `v0.69.x` \~ `v0.72.3`

Due to a bug of `rkyv@0.7.37`, you are recommended to use `nightly-2022-09-23` as the compiler if you are building a plugin for these targets.

- `@swc/core@1.3.40` \~ `@swc/core@1.3.42`
- `next@13.2.5-canary.5`

### `v0.66.x` \~ `v0.68.x`

- `@swc/core@1.3.39`

### `v0.61.x` \~ `v0.64.x`

- `@swc/core@1.3.38`

### `v0.54.x` \~ `v0.59.x`

- `@swc/core@1.3.29` \~ `@swc/core@1.3.37`

- `next@13.2.4-canary.0`\~



---
url: /docs/plugin/ecmascript/getting-started.md
---

# Implementing a plugin

## Important API Changes


⚠️

Recent API changes that may affect your plugin development:
- Replace `chain!` macro with tuples: Use `(` instead of `chain!(`. You can replace all `chain!(` with `(` using IDE features.
- For `chain!` with 13+ arguments: Use nested tuples for items after the 13th element.
- Replace `-> impl Fold` with `-> impl Pass` in general.
- `as_folder` is now `visit_mut_pass` and returns `impl VisitMut + Pass` instead of `impl VisitMut + Fold`.
- Use `Program.apply` and `Program.mutate` to apply Pass to program:
  - `fn apply(self, impl Pass) -> Self`
  - `fn mutate(&mut self, impl Pass)`
- Replace `noop()` with `noop_pass()`. The new function lives in `swc_ecma_ast` and is a real noop function.

## Setup environment

### Install required toolchain

As plugin is written in the rust programming language and built as a `.wasm` file, you need to install rust toolchain and wasm target.

#### Install rust

You can follow instructions at ['Install Rust' page from the official rust website](https://www.rust-lang.org/tools/install)

#### Add wasm target to rust

SWC supports two kinds of `.wasm` files.
Those are

- wasm32-wasip1
- wasm32-unknown-unknown

In this guide, we will use `wasm-wasip1` as a target.

#### Install `swc_cli`

You can install a rust-based CLI for SWC by doing

```sh
cargo install swc_cli
```

#### Configuring IDE

If you are going to use vscode, it's recommended to install `rust-analyzer` extension.
`rust-analyzer` is a [language server](https://microsoft.github.io/language-server-protocol/) for the rust programming language, which provides good features for code completion, code navigation, and code analysis.

## Implementing simple plugin

### Create a project

SWC CLI supports creating a new plugin project.

Run

```sh
swc plugin new --target-type wasm32-wasip1 my-first-plugin
# You should to run this
rustup target add wasm32-wasip1
```

to create a new plugin, and open `my-first-plugin` with your preferred rust IDE.

### Implementing a visitor

The generated code has

```rust
impl VisitMut for TransformVisitor {
    // Implement necessary visit_mut_* methods for actual custom transform.
    // A comprehensive list of possible visitor methods can be found here:
    // https://rustdoc.swc.rs/swc_ecma_visit/trait.VisitMut.html
}
```

which is used to transform code.
[The trait `VisitMut`](https://rustdoc.swc.rs/swc_ecma_visit/trait.VisitMut.html) supports mutating AST nodes, and as it supports all AST types, it has lots of methods.

***

We will use

```js
foo === bar;
```

as the input. From [the SWC Playground](https://play.swc.rs), you can get actual representation of this code.

```json
{
  "type": "Module",
  "span": {
    "start": 0,
    "end": 12,
    "ctxt": 0
  },
  "body": [
    {
      "type": "ExpressionStatement",
      "span": {
        "start": 0,
        "end": 12,
        "ctxt": 0
      },
      "expression": {
        "type": "BinaryExpression",
        "span": {
          "start": 0,
          "end": 11,
          "ctxt": 0
        },
        "operator": "===",
        "left": {
          "type": "Identifier",
          "span": {
            "start": 0,
            "end": 3,
            "ctxt": 0
          },
          "value": "foo",
          "optional": false
        },
        "right": {
          "type": "Identifier",
          "span": {
            "start": 8,
            "end": 11,
            "ctxt": 0
          },
          "value": "bar",
          "optional": false
        }
      }
    }
  ],
  "interpreter": null
}
```

Let's implement a method for `BinExpr`.
You can do it like

```rust
use swc_core::{
    ast::*,
    visit::{VisitMut, VisitMutWith},
};

impl VisitMut for TransformVisitor {
    fn visit_mut_bin_expr(&mut self, e: &mut BinExpr) {
        e.visit_mut_children_with(self);
    }
}
```

Note that `visit_mut_children_with` is required if you want to call the method handler for children.
e.g. `visit_mut_ident` for `foo` and `bar` will be called by `e.visit_mut_children_with(self);` above.

Let's narrow down it using the binary operator.

```rust
use swc_core::{
    ast::*,
    visit::{VisitMut, VisitMutWith},
    common::Spanned,
};

impl VisitMut for TransformVisitor {
    fn visit_mut_bin_expr(&mut self, e: &mut BinExpr) {
        e.visit_mut_children_with(self);

        if e.op == op!("===") {
            e.left = Box::new(Ident::new_no_ctxt("kdy1".into(), e.left.span()).into());
        }
    }
}
```

`op!("===")` is a macro call, and it returns various types of operators.
It returns [BinaryOp](https://rustdoc.swc.rs/swc_ecma_ast/enum.BinaryOp.html) in this case, because we provided `"==="`, which is a binary operator.
See [the rustdoc for op! macro](https://rustdoc.swc.rs/swc_ecma_ast/macro.op.html) for more details.

If we run this plugin, we will get

```js
kdy1 === bar;
```

## Testing your transform

You can simply run `cargo test` to test your plugins.
SWC also provides a utility to ease fixture testing.

You can easily verify the input and output of the transform.

```rust
test!(
    Default::default(),
    |_| visit_mut_pass(TransformVisitor), // Note: Updated to use visit_mut_pass instead of as_folder
    boo,
    r#"foo === bar;"#
);
```

Then, once you run `UPDATE=1 cargo test`, the snapshot will be updated.

You can take a look at [the real fixture test for typescript type stripper](https://github.com/swc-project/swc/blob/c0abdb394a94bcbc7ea9602163e6ce032c89b996/crates/swc_ecma_transforms_typescript/tests/strip.rs#L4514-L4527).

```rust
#[testing::fixture("tests/fixture/**/input.ts")]
#[testing::fixture("tests/fixture/**/input.tsx")]
fn fixture(input: PathBuf) {
    let output = input.with_file_name("output.js");
    test_fixture(
        Syntax::Typescript(TsConfig {
            tsx: input.to_string_lossy().ends_with(".tsx"),
            ..Default::default()
        }),
        &|t| (tr(), properties(t, true)), // Note: Updated to use tuple syntax instead of chain!
        &input,
        &output,
    );
}
```

Things to note:

- The glob provided to `testing::fixture` is relative to the cargo project directory.
- The output file is `output.js`, and it's stored in a same directory as the input file.
- `test_fixture` drives the test.
- You can determine the syntax of the input file by passing the syntax to `test_fixture`.
- You then provide your visitor implementation as the second argument to `test_fixture`.
- Then you provide the input file path and the output file path.

### Logging

SWC uses `tracing` for logging.
By default, SWC testing library configures the log level to `debug` by default, and this can be controlled by using an environment variable named `RUST_LOG`.
e.g. `RUST_LOG=trace cargo test` will print all logs, including `trace` logs.

If you want, you can remove logging for your plugin by using cargo features of `tracing`.
See [the documentation for it](https://docs.rs/crate/tracing/latest/features).

## Publishing your plugin

Please see [plugin publishing guide](/docs/plugin/publishing.md)



---
url: /docs/plugin/ecmascript/cheatsheet.md
---

# Plugin cheatsheet


💡

This page describes the known hard points for implementing plugins for ecmascript.

You may find documentation at [https://rustdoc.swc.rs/swc](https://rustdoc.swc.rs/swc) useful, especially if you are dealing with a visitor or `Id` issue.

## Understanding types

### `JsWord`

`String` allocates, and 'text'-s of source code has a special trait.
Those are lots of duplicates. Obviously, if your variable is named `foo`, you need to use `foo` multiple times.
So SWC interns the string to reduce the number of allocations.

`JsWord` is a string type that is interned.
You can create a `JsWord` from `&str`, or from a `String`.
Use `.into()` to convert to `JsWord`.

### `Ident`, `Id`, `Mark`, `SyntaxContext`

SWC uses a special system for managing variables.
See [the rustdoc for `Ident`](https://rustdoc.swc.rs/swc_ecma_ast/struct.Ident.html) for details.

## Common issues

### Getting AST representation of input

[SWC Playground](https://play.swc.rs) supports getting AST from the input code.

### Variable management of SWC

### Error reporting

See [rustdoc for `swc_common::errors::Handler`](https://rustdoc.swc.rs/swc_common/errors/struct.Handler.html).

### Comparing `JsWord` with `&str`

If you don't know what `JsWord` is, see [the rustdoc for swc\_atoms](https://rustdoc.swc.rs/swc_atoms/).

You can create `&str` by doing `&val` where `val` is a variable of type `JsWord`.

### Matching `Box<T>`

You will need to use `match` to match on various nodes, including `Box<T>`.
For performance reason, all expressions are stored in a boxed form. (`Box<Expr>`)

SWC stores callee of call expressions as a `Callee` enum, and it has `Box<Expr>`.

```rust
use swc_core::ast::*;
use swc_core::visit::{VisitMut, VisitMutWith};

struct MatchExample;

impl VisitMut for MatchExample {
    fn visit_mut_callee(&mut self, callee: &mut Callee) {
        callee.visit_mut_children_with(self);

        if let Callee::Expr(expr) = callee {
            // expr is `Box<Expr>`
            if let Expr::Ident(i) = &mut **expr {
                i.sym = "foo".into();
            }
        }
    }
}
```

### Changing AST type

If you want to change `ExportDefaultDecl` to `ExportDefaultExpr`, you should do it from `visit_mut_module_decl`.

### Inserting new nodes

If you want to inject a new `Stmt`, you need to store the value in the struct, and inject it from `visit_mut_stmts` or `visit_mut_module_items`.
See [a destructuring core transform](https://github.com/swc-project/swc/blob/6416c675de14b3acec558ab7b4ec69afcd71fa11/crates/swc_ecma_transforms_compat/src/es2015/destructuring.rs#L1025-L1034).

```rust
struct MyPlugin {
    stmts: Vec<Stmt>,
}
```

## Tips

### Decorators and TypeScript types

Those are handled before your plugin is called. So you can't access them from the Wasm plugin.
This design decision is made to make Wasm plugins easier to write and the Wasm binary smaller.

- Tracking issue: [https://github.com/swc-project/swc/issues/9132](https://github.com/swc-project/swc/issues/9132)

### Comments while testing

You can make your pass generic over `C: Comments`. `test_fixture` provides `&mut Tester`, which has `comments` field.

- [Example pass](https://github.com/swc-project/swc/blob/2d6509a7d4b29f61d4d29715e6ab0825fa034020/crates/swc_ecma_transforms_react/src/pure_annotations/mod.rs)
- [Testing for the test](https://github.com/swc-project/swc/blob/2d6509a7d4b29f61d4d29715e6ab0825fa034020/crates/swc_ecma_transforms_react/src/pure_annotations/tests.rs#L108-L118)

### Apply `resolver` while testing

SWC applies plugin after applying [`resolver`](https://rustdoc.swc.rs/swc_ecma_transforms_base/fn.resolver.html), so it's better to test your transform with it.
As written in the rustdoc for the `resolver`, you have to use correct `SyntaxContext` if you need to reference global variable (e.g. `__dirname`, `require`) or top-level bindings written by the user.

```rust
fn tr() -> impl Pass {
    (
        resolver(Mark::new(), Mark::new(), false),
        // Most of transform does not care about globals so it does not need `SyntaxContext`
        your_transform()
    )
}

test!(
    Syntax::default(),
    |_| tr(),
    basic,
    // input
    "(function a ([a]) { a });",
    // output
    "(function a([_a]) { _a; });"
);
```

### Make your handlers stateless

Let's say we are going to handle all array expressions in a function expression.
You can add a flag to the visitor to check if we are in a function expression.
You will be tempted to do

```rust
struct Transform {
    in_fn_expr: bool
}

impl VisitMut for Transform {
    noop_visit_mut_type!();

    fn visit_mut_fn_expr(&mut self, n: &mut FnExpr) {
        self.in_fn_expr = true;
        n.visit_mut_children_with(self);
        self.in_fn_expr = false;
    }

    fn visit_mut_array_lit(&mut self, n: &mut ArrayLit) {
        if self.in_fn_expr {
            // Do something
        }
    }
}
```

but this cannot handle

```js
const foo = function () {
    const arr = [1, 2, 3];

    const bar = function () {};

    const arr2 = [2, 4, 6];
}
```

After visiting `bar`, `in_fn_expr` is `false`.
You have to do

```rust
struct Transform {
    in_fn_expr: bool
}

impl VisitMut for Transform {
    noop_visit_mut_type!();

    fn visit_mut_fn_expr(&mut self, n: &mut FnExpr) {
        let old_in_fn_expr = self.in_fn_expr;
        self.in_fn_expr = true;

        n.visit_mut_children_with(self);

        self.in_fn_expr = old_in_fn_expr;
    }

    fn visit_mut_array_lit(&mut self, n: &mut ArrayLit) {
        if self.in_fn_expr {
            // Do something
        }
    }
}
```

instead.

### Test with `@swc/jest`

You can test your transform with `@swc/jest` by adding your plugin to your `jest.config.js`.

```js title="jest.config.js"
module.exports = {
  rootDir: __dirname,
  moduleNameMapper: {
    "css-variable$": "../../dist",
  },
  transform: {
    "^.+\\.(t|j)sx?$": [
      "@swc/jest",
      {
        jsc: {
          experimental: {
            plugins: [
              [
                require.resolve(
                  "../../swc/target/wasm32-wasi/release/swc_plugin_css_variable.wasm"
                ),
                {
                  basePath: __dirname,
                  displayName: true,
                },
              ],
            ],
          },
        },
      },
    ],
  },
};
```

See [https://github.com/jantimon/css-variable/blob/main/test/swc/jest.config.js](https://github.com/jantimon/css-variable/blob/main/test/swc/jest.config.js)

### `Path` is one of unix, while FileName can be one of host OS

This is because linux version of `Path` code is used while compiling to wasm.
So you may need to replace `\\` with `/` in your plugin.
As `/` is a valid path separator in windows, it's valid thing to do.

### Comments

A comment belongs to a span of the node. (lo for leading comments, hi for trailing comments)
If you want to add a leading comment to a node, you can do `PluginCommentsProxy.add_leading(span.lo, comment);`.

See [PluginCommentsProxy](https://rustdoc.swc.rs/swc_plugin_proxy/struct.PluginCommentsProxy.html).

## Ownership model (of rust)

> This section is not about `swc` itself. But this is described at here because it's the cause of almost all trickyness of APIs.

In rust, only one variable can _own_ a data, and there's at most one mutable reference to it.
Also, you need to _own_ the value or have a mutable reference to it if you want to modify the data.

But there's at most one owner/mutable reference, so it means if you have a mutable reference to a value, other code cannot modify the value.
Every update operation should performed by the code which _owns_ the value or has a mutable reference to it.
So, some of babel APIs like `node.delete` is super tricky to implement.
As your code has ownership or mutable refernce to _some_ part of AST, SWC cannot modify the AST.

## Tricky operations

### Deleting node

Let's say, we want to drop the variable named `bar` in the code below.

```js
var foo = 1;
var bar = 1;
```

There are two ways to do this.

#### Mark & Delete

The first way is to mark it as _invalid_ and delete it later.
This is typically more convenient.

```rust
use swc_core::ast::*;
use swc_core::visit::{VisitMut,VisitMutWith};

impl VisitMut for Remover {
    fn visit_mut_var_declarator(&mut self, v: &mut VarDeclarator) {
        // This is not required in this example, but you typically need this.
        v.visit_mut_children_with(self);

        // v.name is `Pat`.
        // See https://rustdoc.swc.rs/swc_ecma_ast/enum.Pat.html
        match v.name {
            // If we want to delete the node, we should return false.
            //
            // Note the `&*` before i.sym.
            // The type of symbol is `JsWord`, which is an interned string.
            Pat::Ident(i) => {
                if &*i.sym == "bar" {
                    // Take::take() is a helper function, which stores invalid value in the node.
                    // For Pat, it's `Pat::Invalid`.
                    v.name.take();
                }
            }
            _ => {
                // Noop if we don't want to delete the node.
            }
        }
    }

    fn visit_mut_var_declarators(&mut self, vars: &mut Vec<VarDeclarator>) {
        vars.visit_mut_children_with(self);

        vars.retain(|node| {
            // We want to remove the node, so we should return false.
            if node.name.is_invalid() {
                return false
            }

            // Return true if we want to keep the node.
            true
        });
    }

    fn visit_mut_stmt(&mut self, s: &mut Stmt) {
        s.visit_mut_children_with(self);

        match s {
            Stmt::Decl(Decl::Var(var)) => {
                if var.decls.is_empty() {
                    // Variable declaration without declarator is invalid.
                    //
                    // After this, `s` becomes `Stmt::Empty`.
                    s.take();
                }
            }
            _ => {}
        }
    }

    fn visit_mut_stmts(&mut self, stmts: &mut Vec<Stmt>) {
        stmts.visit_mut_children_with(self);

        // We remove `Stmt::Empty` from the statement list.
        // This is optional, but it's required if you don't want extra `;` in output.
        stmts.retain(|s| {
            // We use `matches` macro as this match is trivial.
            !matches!(s, Stmt::Empty(..))
        });
    }

    fn visit_mut_module_items(&mut self, stmts: &mut Vec<ModuleItem>) {
        stmts.visit_mut_children_with(self);

        // This is also required, because top-level statements are stored in `Vec<ModuleItem>`.
        stmts.retain(|s| {
            // We use `matches` macro as this match is trivial.
            !matches!(s, ModuleItem::Stmt(Stmt::Empty(..)))
        });
    }
}
```

#### Delete from the parent handler

Another way to delete the node is deleting it from the parent handler.
This can be useful if you want to delete the node only if the parent node is specific type.

e.g. You don't want to touch the variables in for loops while deleting free variable statements.

```rust
use swc_core::ast::*;
use swc_core::visit::{VisitMut,VsiitMutWith};

struct Remover;

impl VisitMut for Remover {
    fn visit_mut_stmt(&mut self, s: &mut Stmt) {
        // This is not required in this example, but just to show that you typically need this.
        s.visit_mut_children_with(self);

        match s {
            Stmt::Decl(Decl::Var(var)) => {
                if var.decls.len() == 1 {
                    match var.decls[0].name {
                        Pat::Ident(i) => {
                            if &*i.sym == "bar" {
                                s.take();
                            }
                        }
                    }
                }
            }
            _ => {}
        }
    }

    fn visit_mut_stmts(&mut self, stmts: &mut Vec<Stmt>) {
        stmts.visit_mut_children_with(self);

        // We do same thing here.
        stmts.retain(|s| {
            !matches!(s, Stmt::Empty(..))
        });
    }

    fn visit_mut_module_items(&mut self, stmts: &mut Vec<ModuleItem>) {
        stmts.visit_mut_children_with(self);

        // We do same thing here.
        stmts.retain(|s| {
            !matches!(s, ModuleItem::Stmt(Stmt::Empty(..)))
        });
    }
}
```

### Referencing parent node from handler of child node

This includes usage of `paths` and `scope`.

### Caching some information about an AST node

You have two way to use informantion from a parent node.
For first, you can precompute information from the parent node handler.
Alternatively, you can clone the parent node and use it in the child node handler.

## Alternatives for babel APIs

### `generateUidIdentifier`

This returns a unique identifier with a monotonically increasing integer suffix.
`swc` does not provide API to do this, because there's a very easy way to do this.
You can store an integer field in transformer type and use it while calling `quote_ident!` or `private_ident!`.

```rust
struct Example {
    // You don't need to share counter.
    cnt: usize
}

impl Example {
    /// For properties, it's okay to use `quote_ident`.
    pub fn next_property_id(&mut self) -> Ident {
        self.cnt += 1;
        quote_ident!(format!("$_css_{}", self.cnt))
    }

    /// If you want to create a safe variable, you should use `private_ident`
    pub fn next_variable_id(&mut self) -> Ident {
        self.cnt += 1;
        private_ident!(format!("$_css_{}", self.cnt))
    }
}
```

### `path.find`

Upward traversal is not supported by `swc`.
It's because upward traversal requires storing information about parent at children nodes, which requires using types like `Arc` or `Mutex` in rust.

Instead of traversing upward, you should make it top-down.
For example, if you want to infer name of a jsx component from variable assignments or assignments, you can store `name` of component while visiting `VarDecl` and/or `AssignExpr` and use it from the component handler.

### `state.file.get`/`state.file.set`

You can simply store the value in the transform struct as an instance of transform struct only process one file.



---
url: /docs/plugin/ecmascript/compatibility.md
---

# Compatibility for wasm plugin

In the past, SWC Wasm plugins were not compatible between `@swc/core` versions. This meant that developers using Wasm plugins often had to update them with each new release of @swc/core to ensure compatibility, and the Wasm plugins maintainers should also update their `swc_core` Rust dependencies. This created friction, added maintenance overhead, and could disrupt development workflows.

However, starting from @swc/core v1.15.0, our Wasm plugins are now compatible between `@swc/core` versions to some extent.

This document explains from the implementation perspective why Wasm plugins were not compatible before, and how you can make your plugins compatible in the new version.

## Background

[WebAssembly (Wasm)](https://webassembly.org/) is designed as a portable compilation target for programming languages, enabling execution within a memory-safe, sandboxed environment. The Wasm artifacts compiled by the SWC Wasm plugin are loaded and executed by runtimes such as Wasmer or Wasmtime within `@swc/core`.

Wasm plugins cannot directly manipulate the Rust AST data structures within the `@swc/core` host environment. Instead, when invoking a Wasm plugin, the host environment serializes the entire AST into a byte array with the [rkyv](https://rkyv.org/) serialization and transmits it to the Wasm runtime. Prior to executing the Wasm plugin, the wasm plugin deserializes the byte array back into a Rust AST and performs the transformation. And then, the wasm plugin serializes the transformed AST back into a byte array and sends it back to the host environment.

![Overview](/static/image/overview.bd3c711b97.png)
**However, a critical issue arises here: the serialization logic and the deserialization are compiled into both the host (`@swc/core`) and the Wasm plugin.** This implies that whenever **`@swc/core` modifies the AST** and releases a new version, the older logic in old Wasm plugins becomes incompatible and ceases to function correctly.

## What SWC has done

There are two primary changes that SWC has implemented to address this issue:

1. **Replacing the serialization scheme [rkyv](https://rkyv.org/) with the self-describing serialization scheme [cbor](https://www.rfc-editor.org/rfc/rfc8949.html).** The rkyv scheme typically requires the ABI layout of serialization and deserialization to match exactly. It is highly sensitive to changes in the memory layout of data structures, and any modification to a field can cause compatibility problems. In contrast, cbor is a self-describing serialization/deserialization scheme that records the memory layout of fields as metadata within the byte array. Although this approach sacrifices some performance and data compactness, it enables the serialization and deserialization process to be aware of changes in the data structure.

2. **Making enums extensible.** For each AST enum data type, SWC has added an `Unknown` variant to accommodate differences in data between different versions of `@swc/core` and Wasm plugins. This allows data introduced in newer versions of `@swc/core`, which older versions of the plugin cannot recognize—to, be preserved across serialization and deserialization.

To clarify, based on the above technical principles, SWC does not resolve all compatibility issues, such as those caused by field deletions or changes in field types. In practice, these cases are relatively rare since changes to the AST data structures primarily arise from support for new ECMAScript standards. Therefore, we continue to minimize the frequency of breaking changes in Wasm plugins through CI checks and version release strategies.

## Make your plugin compatible

It's very simple to enable your Wasm plugin to benefit from the aforementioned changes.

1. Make sure your Wasm plugin depends on `swc_core >= 47`.
2. Enable `swc_ast_unknown` cfg in your `.cargo/config.toml` file.

```toml
[target.'cfg(target_arch = "wasm32")']
rustflags = [
  "--cfg=swc_ast_unknown"
]
```

3. For each pattern-match code with ast enum, add a match arm for the `Unknown` variant, and just `panic!()` it. For example:

```rs
match imported {
    ModuleExportName::Ident(v) => v.sym == exported.name,
    ModuleExportName::Str(v) => {
        v.value.as_str() == Some(exported.name.as_str())
    }
    #[cfg(swc_ast_unknown)]
    _ => panic!("unknown node")
}
```

Why is it the `panic!()` here? What's the difference between the old version and the new version with `panic!()`? Consider a scenario where ECMAScript introduces a new type of AST node. With the older version of SWC, the Wasm plugin would fail immediately during the deserialization, regardless of whether the actual code or the parsed AST contains the newly introduced node type. In contrast, with the newer version of SWC, the Wasm plugin is able to work correctly on ASTs that do not contain the new node type.



---
url: /docs/plugin/publishing.md
---

# Publishing plugins

If you prefer reading codes, you can refer to [the repository for official plugins](https://github.com/swc-project/plugins).

## Register on plugins.swc.rs

After publishing your plugin package, add it to the plugin crawler index so it appears on [plugins.swc.rs](https://plugins.swc.rs).

See [Registering plugins](/docs/plugin/registering-plugins.md) for the step-by-step guide.

## Creating a npm package

### Building a plugin as a wasm

You can run your plugin as a wasm file by running

```sh
cargo build-wasi --release // build wasm32-wasi target binary
cargo build-wasm32 --release // build wasm32-unknown-unknown target binary
```

It will create `target/wasm32-wasi/release/your_plugin_name.wasm` or `target/wasm32-unknown-unknown/release/your_plugin_name.wasm`, depending on your config.

### Creating a npm package for plugin

Add the following to your `package.json`:

```json title="package.json"
{
    "main": "your_plugin_name.wasm",
    "scripts": {
        "prepack": "cargo prepublish --release && cp target/wasm32-wasi/release/your_plugin_name.wasm ."
    },
}
```

## Advanced: Improving your plugin

### Adjusting configuration for smaller binary

You can reduce the size of the plugin by configuring cargo.

In your `Cargo.toml` file, you can add the following lines.

```toml title="Cargo.toml"
[profile.release]
# This removes more dead code
codegen-units = 1
lto = true
# Optimize for size
opt-level = "s"
# Optimize for performance, this is default so you don't need to specify it
# opt-level = "z"

# Strip debug symbols
strip = "symbols"
```

### Removing log for release mode

If logging of your crate is too much, you can remove it by enabling `release_max_level_*` of `tracing`, like

```toml
tracing = { version="0.1", features = ["release_max_level_info"] }
```



---
url: /docs/plugin/registering-plugins.md
---

# Registering plugins on plugins.swc.rs

If you want your Wasm plugin to appear on [plugins.swc.rs](https://plugins.swc.rs), submit a pull request to [swc-project/crawl-core-version](https://github.com/swc-project/crawl-core-version/tree/main/pkgs/plugins).

The crawler reads plugin definitions from [`pkgs/plugins/*.yml`](https://github.com/swc-project/crawl-core-version/tree/main/pkgs/plugins).

## 1. Add a `.yml` file under `pkgs/plugins`

Create a file like `pkgs/plugins/your-plugin.yml`:

```yml
repo: https://github.com/your-org/your-plugin-repo.git
packages:
  - "@your-org/swc-plugin-foo"
  - "@your-org/swc-plugin-bar"
```

## 2. Open a pull request

Commit the new `.yml` file and open a PR against `main` in `crawl-core-version`.

## Rules and notes

- Only files ending with `.yml` are crawled.
- Each entry in `packages` must exactly match the npm package name.
- A single file can include multiple npm packages from the same repository.
- `repo` should be a cloneable Git repository URL.

## When will it show up on plugins.swc.rs?

After your PR is merged, data is updated by the [`Auto Update` workflow](https://github.com/swc-project/crawl-core-version/blob/main/.github/workflows/auto-update.yml) in `crawl-core-version` (scheduled daily, and also runnable manually). Once that update runs, your plugin data can appear on `plugins.swc.rs`.

## See also

- [Publishing plugins](/docs/plugin/publishing.md)
- [Selecting swc\_core](/docs/plugin/selecting-swc-core.md)



---
url: /docs/contributing/commons/string-management.md
---

# String Management

## String Interning

See \[`hstr`]\[] for more details.

SWC interns strings if it's not too short nor too long.
This is useful for reducing memory usage and improving performance because SWC is a sort of compiler.
Many variables share the same string, and we have to perform lots of hash operations on them.

It does not intern too short strings because we can avoid allocations for them.
It does not intern too long strings because it's not worth it.
Typically, long strings are not same to each other.

While interning strings, SWC calculates the hash of the string.
It makes `hash()` `O(1)`. `eq` becomes much faster although it's not strictly `O(1)`.

[hstr]: https://docs.rs/hstr



---
url: /docs/contributing/es-commons/variable-management.md
---

# Variable Management

SWC uses a very unique way to manage variables.

## Syntax context

SWC uses a syntax context to manage variables. Internals are documented at [the rustdoc of the `resolver` pass](https://rustdoc.swc.rs/swc_core/ecma/transforms/base/fn.resolver.html).

Basically the order of processing is like this. This processing should be wrapped by `GLOBALS.set(&Default::default(), || { ... })`.

- `resolver`
- `your_pass` (can be multiple passes)
- `hygiene`
- `fixer` (Optional, but if your transform may produce invalid syntax, this would add necessary parentheses)

## Terms

A `private identifier` is a identifier that is guaranteed to be unique, and it's renamed by the `hygiene` pass if there's a conflict.

## Creating a private identifier

You can use `Ident::new_private` to create a private identifier. Note that this requires an access to `GLOBALS`, which is a scoped thread-local storage.

```rust
let id = Ident::new_private("my_var");
```

## Full example

Full example:

```rust
GLOBALS.set(&Default::default(), || {
  let unresolved_mark = Mark::new();
  let top_level_mark = Mark::new();

  // https://rustdoc.swc.rs/swc_core/ecma/transforms/base/fn.resolver.html
  program.mutate(resolver(unresolved_mark, top_level_mark, is_your_input_file_typescript));

  // Apply your transforms and use Ident::new_private from there
  program.mutate(your_pass);
  // or
  program.visit_mut_with(your_pass);
  // or
  program = program.fold(your_pass);



  // https://rustdoc.swc.rs/swc_core/ecma/transforms/base/hygiene/fn.hygiene.html
  program.mutate(hygiene());

})
```



---
url: /docs/contributing/es-minifier/profiling.md
---

# Profiling

## Common Profiling Steps

If you have a problem with SWC minifier about memory allocation and you are on mac, you can use [`ddt`][] to profile the memory usage.
Also, many steps are common to any kind of profiling.

### Step 1. Prepare the inputs

If you want to check the example directory for inputs, you can take a look at [https://github.com/kdy1/swc-minifier-inputs](https://github.com/kdy1/swc-minifier-inputs).
These input files are extracted from real next.js projects publicly available on github.
See [debugging-nextjs-app](/docs/contributing/es-minifier/debugging-nextjs-app.md) for more details.

In this example, we will assume that the link above is cloned to `~/projects/minifier-inputs`.
(i.e. `git clone https://github.com/kdy1/swc-minifier-inputs.git ~/projects/minifier-inputs`)

Replace `~/projects/minifier-inputs` in the commands below with the directory containing your input files. It can be either a file or a directory containing the input files.
All .js files will be minified, without writing the result to the disk.

#### Step 2. Clone the repository

```bash
git clone https://github.com/swc-project/swc.git
cd ./swc/crates/swc_ecma_minifier
```

## Profiling Time Usage

### Step 3. Run the profiler

You have two options. One is to use `samply`, which is cross-platform, and the other is to use XCode Instruments, which is only available on mac.

#### Using `samply`

```bash
CARGO_PROFILE_RELEASE_DEBUG=1 RUST_LOG=off ddt profile samply cargo --release --features concurrent --example minify-all -- ~/projects/minifier-inputs  to the directory containing your input files. It can be either a file or a directory containing the input files. All .js files will be minified (without writing the result to the disk)
```

This will open a tab in your browser once the profiling is done.

#### Using XCode Instruments

```bash
CARGO_PROFILE_RELEASE_DEBUG=1 RUST_LOG=off ddt profile instruments cargo -t time --release --features concurrent --example minify-all -- ~/projects/minifier-inputs  to the directory containing your input files. It can be either a file or a directory containing the input files. All .js files will be minified (without writing the result to the disk)
```

This will open the Instruments app once the profiling is done.

## Profiling Memory Usage

### Step 3. Run the profiler

The command to run the profiler is as follows:

```bash
CARGO_PROFILE_RELEASE_DEBUG=1 RUST_LOG=off ddt profile instruments cargo -t 'Memory' --release --features concurrent --example minify-all -- ~/projects/minifier-inputs  to the directory containing your input files. It can be either a file or a directory containing the input files. All .js files will be minified (without writing the result to the disk)
```

This will open the Instruments app once the profiling is done.

***

[`ddt`]: https://github.com/swc-project/ddt



---
url: /docs/contributing/es-minifier/debugging-nextjs-app.md
---

# Debugging Next.js App

## Steps to extract the inputs to the SWC minifier.

### Step 1. Clone the SWC repository

You would need to clone the SWC repository to your local machine, and invoke a script in the repository from the project root of your next.js app.
So in this example, we will assume that the link above is cloned to `~/projects/swc`.

```bash
git clone https://github.com/swc-project/swc.git ~/projects/swc
```

### Step 2. Do everything except the `next build` step.

This depends on your project.
You should install all the dependencies, run the dependency tasks for your next.js app, like the ones invoked automatically by monorepo management tools like `turbo`.

### Step 3. Invoke the script

```bash
~/projects/swc/crates/swc_ecma_minifier/scripts/next/add-test.sh
```

This will run the `next build` step, and it will copy all inputs to the SWC minifier into test directory of your SWC clone.
You can move those files to your minifier inputs directory.

The lead maintainer (@kdy1) maintains a repository for the minifier inputs at [https://github.com/kdy1/swc-minifier-inputs](https://github.com/kdy1/swc-minifier-inputs) to profile the performance of the minifier.



---
url: /docs/contributing/es-minifier/debugging-size.md
---

# Debugging size difference between SWC and Terser

you can use `dbg-swc` to spot input files that is larger with SWC minifier than terser.

## Step 1. Installation

1. Install rust ([https://rustup.rs/](https://rustup.rs/))
2. `cargo install dbg-swc`

## Step 2. Run dbg-swc

Note that it may take a while to run because it will run `terser`, which is a heavy process, for each input file.

```bash
dbg-swc es minifier ensure-size path/to/your/minifier/inputs

# e.g.
# dbg-swc es minifier ensure-size ~/projects/minifier-inputs
```

## Step 3. Check the result

It prints all the files that are larger with SWC minifier than `terser`.

```
/Users/kdy1/projects/minifier-inputs/formbricks-webapp/7513/input.js
  No-mangle
    swc: 1474171 bytes
    terser: 1454104 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/4011/input.js
  Gzipped
    swc: 100759 bytes
    terser: 99564 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/app/(app)/environments/[environmentId]/settings/(organization)/billing/page/input.js
  Gzipped
    swc: 36019 bytes
    terser: 35937 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/1469/input.js
  Gzipped
    swc: 8795 bytes
    terser: 8769 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/app/(app)/environments/[environmentId]/settings/(organization)/general/page/input.js
  Gzipped
    swc: 22059 bytes
    terser: 22029 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/5138/input.js
  Gzipped
    swc: 54356 bytes
    terser: 54209 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/1055/input.js
  Gzipped
    swc: 54361 bytes
    terser: 54214 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/app/api/billing/stripe-webhook/route/input.js
  Gzipped
    swc: 21439 bytes
    terser: 21420 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/app/(app)/environments/[environmentId]/integrations/page/input.js
  Gzipped
    swc: 19111 bytes
    terser: 19083 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/9103/input.js
  Gzipped
    swc: 10173 bytes
    terser: 10159 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/92/input.js
  Gzipped
    swc: 10095 bytes
    terser: 10071 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/4105/input.js
  Gzipped
    swc: 9259 bytes
    terser: 9190 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/app/(app)/environments/[environmentId]/settings/(organization)/enterprise/page/input.js
  Gzipped
    swc: 12698 bytes
    terser: 12632 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/2615/input.js
  Gzipped
    swc: 9645 bytes
    terser: 9591 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/2171/input.js
  Gzipped
    swc: 7003 bytes
    terser: 6994 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/9242/input.js
  Gzipped
    swc: 5069 bytes
    terser: 4982 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/255/input.js
  Gzipped
    swc: 4775 bytes
    terser: 4761 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/6626/input.js
  Gzipped
    swc: 7811 bytes
    terser: 7760 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/1606/input.js
  Gzipped
    swc: 14604 bytes
    terser: 14502 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/4150/input.js
  Gzipped
    swc: 12041 bytes
    terser: 11926 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/app/page/input.js
  Gzipped
    swc: 4867 bytes
    terser: 4860 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/app/[shortUrlId]/page/input.js
  Gzipped
    swc: 4265 bytes
    terser: 4253 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/4483/input.js
  No-mangle
    swc: 23857 bytes
    terser: 23777 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/6916/input.js
  Gzipped
    swc: 1812 bytes
    terser: 1806 bytes
  Mangled
    swc: 4335 bytes
    terser: 4311 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/571/input.js
  Gzipped
    swc: 1812 bytes
    terser: 1805 bytes
  Mangled
    swc: 4334 bytes
    terser: 4310 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/edge-runtime-webpack/input.js
  Mangled
    swc: 1947 bytes
    terser: 1890 bytes
  No-mangle
    swc: 3758 bytes
    terser: 3723 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/webpack-runtime/input.js
  Gzipped
    swc: 861 bytes
    terser: 842 bytes
  Mangled
    swc: 1683 bytes
    terser: 1585 bytes
  No-mangle
    swc: 3320 bytes
    terser: 3262 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/8991/input.js
  Gzipped
    swc: 15466 bytes
    terser: 15413 bytes
  Mangled
    swc: 60682 bytes
    terser: 59783 bytes

/Users/kdy1/projects/minifier-inputs/formbricks-webapp/instrumentation/input.js
  Gzipped
    swc: 89232 bytes
    terser: 88325 bytes
  Mangled
    swc: 345209 bytes
    terser: 343076 bytes
  No-mangle
    swc: 407779 bytes
    terser: 404269 bytes
Total
  swc: 36565606 bytes
  terser: 36969776 bytes
  Size ratio: 0.9890675561572242
swc produced smaller or equal output for 236 files out of 242 files, 97.52%
Total (gzipped)
  swc: 5605826 bytes
  terser: 5654953 bytes
  Size ratio: 0.991312571474953
swc produced smaller or equal output for 216 files out of 242 files, 89.26%

```

## Step 4. Debug the size difference

If you think there's a bug in the SWC minifier, please file an issue at [https://github.com/swc-project/swc/issues](https://github.com/swc-project/swc/issues).



---
url: /docs/team.md
---

# The Team

SWC is a community-driven project.


[![kdy1 / Donny avatar](https://github.com/kdy1.png)kdy1 / DonnyLead Maintainer](https://github.com/kdy1)[![OJ Kwon avatar](https://github.com/kwonoj.png)OJ KwonCore Team](https://github.com/kwonoj)[![magic-akari avatar](https://github.com/magic-akari.png)magic-akariCore Team](https://github.com/magic-akari)[![Austaras avatar](https://github.com/Austaras.png)AustarasCore Team](https://github.com/Austaras)[![CPunisher avatar](https://github.com/CPunisher.png)CPunisherCore Team](https://github.com/CPunisher)[![bohan avatar](https://github.com/bvanjoi.png)bohanCore Team](https://github.com/bvanjoi)[![LongYinan avatar](https://github.com/Brooooooklyn.png)LongYinanMaintainer of @swc-node/*](https://github.com/Brooooooklyn)


---
url: /docs/roadmap.md
---

# Development Roadmap

## Important tasks

## Align AST to Babel/typescript-eslint

- Reduces AST-related Wasm breaking changes.

## Reduce binary size by merging visitors

- Reduces the binary size and improves the performance of transform passes.

## Wasm plugin backward compatibility

WIP.

## Minifier/parser perf improvement

## Decorator support

## node\_id for AST nodes

These fields will be used for performance optimization.



---
url: /docs/sponsors.md
---

# Sponsors

SWC is a widely used open source project. It is used by many companies and organizations. We are grateful to all of our sponsors for their support.

If you found SWC useful, please consider sponsoring us.

- [GitHub Sponsors](https://github.com/sponsors/swc-project)
- [Open Collective](https://opencollective.com/swc)

![Sponsors](https://raw.githubusercontent.com/swc-project/swc-sponsor-images/main/sponsors.svg)



---
url: /docs/customers.md
---

# Customers

SWC is used by many companies


[![Vercel](/img/customers/vercel.svg)](https://vercel.com/?utm_source=swc&utm_medium=customers_page)[![ByteDance](/img/customers/bytedance.png)](https://bytedance.com/?utm_source=swc&utm_medium=customers_page)[![Tencent](/img/customers/tencent.svg)](https://tencent.com/?utm_source=swc&utm_medium=customers_page)[![Shopify](/img/customers/shopify.svg)](https://shopify.com/?utm_source=swc&utm_medium=customers_page)[![Supabase](/img/customers/supabase.png)](https://supabase.com/?utm_source=swc&utm_medium=customers_page)[![Miro](/img/customers/miro.svg)](https://miro.com/?utm_source=swc&utm_medium=customers_page)[![X.com](/img/customers/x.svg)](https://x.com/?utm_source=swc&utm_medium=customers_page)[![Microsoft](/img/customers/microsoft.png)](https://www.microsoft.com/?utm_source=swc&utm_medium=customers_page)[![Ant Group](/img/customers/antgroup.png)](https://www.antgroup.com/?utm_source=swc&utm_medium=customers_page)[![Parcel](/img/customers/parceljs.png)](https://parceljs.org/?utm_source=swc&utm_medium=customers_page)[![Deno](/img/customers/deno.svg)](https://deno.land/?utm_source=swc&utm_medium=customers_page)[![Framer](/img/customers/framer.svg)](https://framer.com/?utm_source=swc&utm_medium=customers_page)[![Fundamentei](/img/customers/fundamentei.png)](https://fundamentei.com/?utm_source=swc&utm_medium=customers_page)[![strapi](/img/customers/strapi.svg)](https://strapi.io/?utm_source=swc&utm_medium=customers_page)[![octopol](/img/customers/octopol.jpeg)](https://octopol.io/?utm_source=swc&utm_medium=customers_page)[![Pollen](/img/customers/pollen.png)](https://team.pollen.co/?utm_source=swc&utm_medium=customers_page)[![Trip.com](/img/customers/trip.png)](https://trip.com/?utm_source=swc&utm_medium=customers_page)[![Trip.biz](/img/customers/tripbiz.svg)](https://trip.biz/?utm_source=swc&utm_medium=customers_page)[![Transloadit](/img/customers/transloadit.svg)](https://transloadit.com/?utm_source=swc&utm_medium=customers_page)[![Affine](/img/customers/affine.svg)](https://affine.pro/?utm_source=swc&utm_medium=customers_page)[![APIMaker](/img/customers/apimaker.svg)](https://apimaker.dev/?utm_source=swc&utm_medium=customers_page)[![MediaBoard](/img/customers/mediaboard.svg)](https://mediaboard.com/?utm_source=swc&utm_medium=customers_page)[![Galaxus](/img/customers/galaxus.jpg)](https://www.galaxus.ch/en?utm_source=swc&utm_medium=customers_page)[![Digitec](/img/customers/digitec.jpg)](https://www.digitec.ch/en?utm_source=swc&utm_medium=customers_page)[![Wayfair](/img/customers/wayfair.svg)](https://www.wayfair.com/?utm_source=swc&utm_medium=customers_page)[![Fireworks](/img/customers/fireworks.svg)](https://fireworks.ai/?utm_source=swc&utm_medium=customers_page)[![Landfolk](/img/customers/landfolk.svg)](https://landfolk.com/?utm_source=swc&utm_medium=customers_page)[![Hennge](/img/customers/hennge.svg)](https://hennge.com/?utm_source=swc&utm_medium=customers_page)[![Verkada](/img/customers/verkada.png)](https://www.verkada.com/?utm_source=swc&utm_medium=customers_page)[![The MEDIA ANT](/img/customers/the-media-ant.webp)](https://www.themediaant.com/?utm_source=swc&utm_medium=customers_page)[![EverShop](/img/customers/evershop.png)](https://evershop.io/?utm_source=swc&utm_medium=customers_page)[![Nodecraft](/img/customers/nodecraft.svg)](https://nodecraft.com/?utm_source=swc&utm_medium=customers_page)[![Trellis](/img/customers/trellis.png)](https://trellis.org/?utm_source=swc&utm_medium=customers_page)[![Faire](/img/customers/faire.svg)](https://www.faire.com/?utm_source=swc&utm_medium=customers_page)


---
url: /docs/benchmarks.md
---

# Benchmarks

These benchmarks are used to evaluate the performance of SWC on every commit, as well as against other libraries like Babel or esbuild. You can view the [benchmark source code here](https://github.com/swc-project/swc/blob/main/.github/workflows/bench.yml).

Loading...
## Transformations (Parallel)

This is the most important benchmark, since build tool authors will run tasks concurrently. Note the performance of Babel and `tsx` is indentical for parallel and synchronous benchmarks.

You can view the [benchmark source code here](https://github.com/kdy1/benchmark-done-right).

### es3

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es3.png)

### es5

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es5.png)

### es2015

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es2015.png)

### es2016

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es2016.png)

### es2017

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es2017.png)

### es2018

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es2018.png)

### es2019

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es2019.png)

### es2020

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/parallel/es2020.png)

## Transformations (Synchronous)

Not as critical as the parallel benchmark.

### es3

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es3.png)

### es5

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es5.png)

### es2015

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es2015.png)

### es2016

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es2016.png)

### es2017

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es2017.png)

### es2018

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es2018.png)

### es2019

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es2019.png)

### es2020

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/sync/es2020.png)

## Transformations (Asynchronous)

This benchmark suite does not use all CPU cores. For SWC, the benchmark stores only one task on the Node.js thread pool at a time.

### es3

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es3.png)

### es5

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es5.png)

### es2015

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es2015.png)

### es2016

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es2016.png)

### es2017

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es2017.png)

### es2018

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es2018.png)

### es2019

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es2019.png)

### es2020

![Benchmark](https://raw.githubusercontent.com/kdy1/benchmark-done-right/main/images/transform/async/es2020.png)



---
url: /docs/references/wasm-typescript.md
---

# @swc/wasm-typescript

## Installation


```sh [npm]
npm install @swc/wasm-typescript
```

```sh [yarn]
yarn add @swc/wasm-typescript
```

```sh [pnpm]
pnpm add @swc/wasm-typescript
```

```sh [bun]
bun add @swc/wasm-typescript
```

```sh [deno]
deno add npm:@swc/wasm-typescript
```

### Usage

```ts twoslash
import { transform } from '@swc/wasm-typescript';

const tsSourceCode = `
export function add(a: number, b: number) {
    return a + b;
}
`;

const code = await transform(tsSourceCode, {

})
```

## APIs

### transform, transformSync

- Signature: `function transform(src: string, options: Options) => Promise<string>`
- Signature: `function transformSync(src: string, options: Options) => string`

### Types

```typescript
type Options = {
    // Defaults to 'unknown', which automatically detects the module type.
    module?: boolean | 'unknown'

    filename?: string;

    parser?: TsSyntax
}
```



---
url: /docs/migrating-from-babel.md
---

# Migrating from Babel

SWC's [compilation](/docs/configuration/compilation.md) is intended to support all ECMAScript features. The SWC CLI is designed to be a drop-in replacement for Babel:

```plaintext
$ npx babel # old
$ npx swc # new
```

SWC supports **all stage 3 proposals**, and preset-env, including bugfix transforms.



---
url: /docs/migrating-from-tsc.md
---

# Migrating from tsc

If you are Migrating from TypeScript Compiler(tsc), there are a few things to keep in mind.

## TypeScript version

SWC supports the latest stable TypeScript.

## isolatedModules: true

SWC works on file-by-file, so any code transforms that depend on understanding the full type system will not work.

If you encounter these limitations, certain TypeScript features such as const enums and namespaces may cause runtime problems.

In this case, using the [`isolatedModules`][isolatedmodules] flag in TypeScript can help to warn you of any code that may not be correctly interpreted by SWC.

See [a comment on the related issue](https://github.com/swc-project/swc/issues/7101#issuecomment-1480610668) for more details.

[isolatedmodules]: https://www.typescriptlang.org/tsconfig#isolatedModules

## importsNotUsedAsValues: "error"

Due to the aforementioned reasons, SWC is unable to completely discern whether the imported binding is a `value` or a `type`.

Setting this [`importsNotUsedAsValues`][importsnotusedasvalues] option to `error` will ensure that TypeScript properly marks all type imports during type checking as `type`, thus removing them accurately in SWC.

[importsnotusedasvalues]: https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues

## esModuleInterop: true

The TypeScript's import interoperability deviates from the ES6 modules specification.

SWC, on the other hand, adopts a similar approach to Babel (which can sometimes be more stringent).

Enabling this [esModuleInterop][esmoduleinterop] option ensures that tsc's behavior aligns with that of SWC.

[esmoduleinterop]: https://www.typescriptlang.org/tsconfig#esModuleInterop

## verbatimModuleSyntax: true

This is a new option introduced in TypeScript 5.0 to replace `isolatedModules`, `preserveValueImports` and `importsNotUsedAsValues`.
Please check the [release note][verbatimmodulesyntax] for further details.

[verbatimmodulesyntax]: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0-beta/#verbatimmodulesyntax

## useDefineForClassFields

This issue involves the semantics of `[[Define]]` and `[[Set]]`.

Who does not need to take care of it?

- Those who never use classes.
- Those who use classes but never use inheritance.

Who needs to pay special attention to this matter?

- Decorator users.

If the value has already been set in your `tsconfig.json`, then the same value can be used in the configuration of swc.

If it has not been set and you encounter a problem, then it is necessary for you to supplement this setting.

It should be noted that the default value of this option will change depending on the `target` of your `tsconfig.json`.

Please check the [useDefineForClassFields][usedefineforclassfields] option.

> true if target is ES2022 or higher, including ESNext, false otherwise.

[usedefineforclassfields]: https://www.typescriptlang.org/tsconfig#useDefineForClassFields

## Known issues

- [TypeScript#16166](https://github.com/microsoft/TypeScript/issues/16166)
  ES6 imports are not hoisted by tsc. If you rely on erroneous tsc implementation, you may encounter issues when migrating to swc, as swc more rigorously preserves ES module semantics.

## Notes

SWC only transpiles the code and doesn't perform type checking.
Therefore, it's recommended that you continue to use tsc for detecting any type errors.



---
url: /docs/swc-node-vs-swc.md
---

# `@swc-node/*` vs `@swc/*`

`@swc-node` is a package that wraps `@swc/core` and supports `tsconfig.json`.
Both packages are actively maintained.



---
url: /playground/index.md
---




---
url: /blog/perf-swc-vs-babel.md
---

# Performance Comparison of SWC and Babel


January 31st, 2020 by [DongYoon Kang](https://twitter.com/kdy1dev)

JavaScript is single-threaded. The JS thread is not a good place to do heavy computation. Let's talk about `babel` and `swc`, which are both computation-heavy.

## Synchronous Benchmark

Let's do a benchmark for the single-core workload. Note this uses `transformSync`, which is rarely useful in the wild.

```sh
[transform]
  swc (es3) x 616 ops/sec ±4.36% (88 runs sampled)
  swc (es2015) x 677 ops/sec ±2.01% (90 runs sampled)
  swc (es2016) x 1,963 ops/sec ±0.45% (93 runs sampled)
  swc (es2017) x 1,971 ops/sec ±0.35% (94 runs sampled)
  swc (es2018) x 2,555 ops/sec ±0.35% (93 runs sampled)
  swc-optimize (es3) x 645 ops/sec ±0.40% (90 runs sampled)
  babel (es5) x 34.05 ops/sec ±1.15% (58 runs sampled)
```

SWC is very fast. Although `swc (es3)` does more work than `babel (es5)`, `swc (es3)` is faster than `babel (es5)`.

## Real-World Benchmark

`transformSync` and `transformFileSync` are rarely used in the real world, as it blocks the current thread. `await Promise.all()` is frequently used as is better than:

```js
for (const promise of promises) {
  await promise;
}
```

Let's create a benchmark for actual real-world usage using `Promise.all()`.

### Ideal Case

First, I created a benchmark for the _ideal_ case. It invokes `[n]` promises at once where `n` is the number of physical CPU cores. See [node-swc repository](https://github.com/swc-project/node-swc/blob/bf7718049d67148e2094d0e431d71d4a21993ec7/benches/multicore.js) for the full code.

```js
const os = require("os");
const cpuCount = os.cpus().length;

const SOURCE = `
  // See the link above
`;

const SUITES = [
  // ...
  // See the link above
];

const arr = [];
for (let i = 0; i < cpuCount / 2; i++) {
  arr.push(0);
}

console.info(`CPU Core: ${cpuCount}; Parallelism: ${arr.length}`);
console.info(
  `Note that output of this benchmark should be multiplied by ${arr.length} as this test uses Promise.all`
);

SUITES.map(args => {
  const [name, requirePath, fn] = args;
  const func = fn.bind(null, require(requirePath));
  bench(name, async done => {
    await Promise.all(arr.map(v => func()));
    done();
  });
});
```

I ran benchmarks on my old desktop. It has E3-v1275 and 24GB of ram. The output below is copied as-is from benchmark output.

```sh
CPU Core: 8; Parallelism: 4
Note that output of this benchmark should be multiplied by 4 as this test uses Promise.all
[multicore]
swc (es3) x 426 ops/sec ±3.75% (73 runs sampled)
swc (es2015) x 422 ops/sec ±3.57% (74 runs sampled)
swc (es2016) x 987 ops/sec ±2.53% (75 runs sampled)
swc (es2017) x 987 ops/sec ±3.44% (75 runs sampled)
swc (es2018) x 1,221 ops/sec ±2.46% (77 runs sampled)
swc-optimize (es3) x 429 ops/sec ±1.94% (82 runs sampled)
babel (es5) x 6.82 ops/sec ±17.18% (40 runs sampled)
```

Now, we need to multiply it by 4, as we do 4 operations per iteration.

```sh
swc (es3) x 1704 ops/sec ±3.75% (73 runs sampled)
swc (es2015) x 1688 ops/sec ±3.57% (74 runs sampled)
swc (es2016) x 3948 ops/sec ±2.53% (75 runs sampled)
swc (es2017) x 3948 ops/sec ±3.44% (75 runs sampled)
swc (es2018) x 4884 ops/sec ±2.46% (77 runs sampled)
swc-optimize (es3) x 1716 ops/sec ±1.94% (82 runs sampled)
babel (es5) x 27.28 ops/sec ±17.18% (40 runs sampled)
```

This is an actual result.

The performance of `babel (es5)` is dropped. Async is not free. Even though, `34.05 ops/sec` => `27.28 ops/sec` is much better than I expected.

### Benchmark for Many Operations

I modified the benchmark file slightly to make it creates 100 promises per iteration.

```sh
CPU Core: 8; Parallelism: 100
Note that output of this benchmark should be multiplied by 100 as this test uses Promise.all
[multicore]
  swc (es3) x 21.99 ops/sec ±1.83% (54 runs sampled)
  swc (es2015) x 19.11 ops/sec ±3.39% (48 runs sampled)
  swc (es2016) x 55.80 ops/sec ±6.97% (71 runs sampled)
  swc (es2017) x 62.59 ops/sec ±2.12% (74 runs sampled)
  swc (es2018) x 81.08 ops/sec ±5.22% (75 runs sampled)
  swc-optimize (es3) x 18.60 ops/sec ±2.13% (50 runs sampled)
  babel (es5) x 0.32 ops/sec ±19.10% (6 runs sampled)
```

It must be multiplied by 100 as above.

```sh
  swc (es3) x 2199 ops/sec ±1.83% (54 runs sampled)
  swc (es2015) x 1911 ops/sec ±3.39% (48 runs sampled)
  swc (es2016) x 5580 ops/sec ±6.97% (71 runs sampled)
  swc (es2017) x 6259 ops/sec ±2.12% (74 runs sampled)
  swc (es2018) x 8108 ops/sec ±5.22% (75 runs sampled)
  swc-optimize (es3) x 1860 ops/sec ±2.13% (50 runs sampled)
  babel (es5) x 32 ops/sec ±19.10% (6 runs sampled)
```

Why does the performance of SWC not drop drastically? The secret is Node.js. Node.js internally manages a worker thread pool, and SWC runs on it. Thus, even though you create 100 promises at once, the number of worker threads is much smaller than it.

## Conclusion

|        name        |  1 core, sync |   4 promises  | 100 promises |
| :----------------: | :-----------: | :-----------: | :----------: |
|      swc (es3)     |  616 ops/sec  |  1704 ops/sec | 2199 ops/sec |
|    swc (es2015)    |  677 ops/sec  |  1688 ops/sec | 1911 ops/sec |
|    swc (es2016)    |  1963 ops/sec | 3948 op s/sec | 5580 ops/sec |
|    swc (es2017)    |  1971 ops/sec |  3948 ops/sec | 6259 ops/sec |
|    swc (es2018)    |  2555 ops/sec |  4884 ops/sec | 8108 ops/sec |
| swc-optimize (es3) |  645 ops/sec  |  1716 ops/sec | 1860 ops/sec |
|     babel (es5)    | 34.05 ops/sec | 27.28 ops/sec |  32 ops/sec  |

`swc` scales well, as it does almost all work in the worker thread. From the fact that the throughput of `100 promises` was better than `4 promises`, we can conclude that the worker thread pool of Node.js utilizes hyperthreading.

`swc` scales up with the number of cpu cores. `Promise.all` is enough for scaling.



---
url: /blog/swc-1.md
---

# Introducing SWC 1.0


February 8th, 2019 by [DongYoon Kang](https://twitter.com/kdy1dev)

## What is SWC?

[swc](https://github.com/swc-project/swc) (speedy web compiler) is a super-fast JavaScript compiler.

## What can SWC do?

It can transpile TypeScript / jsx / ECMAScript 2019 to browser-compatible JavaScript.

```js
// input.js

class Foo {
  set foo(v) {}
}
class Bar extends Foo {
  get bar1() {}
  async bar2() {}
}
```

## How fast is SWC?

It's 16x - 20x faster than babel even on single-core synchronous benchmark. Note that actual performance gap is larger because swc works on worker thread while babel works on event loop thread.

## Installation

You can install `swc` with

```sh
# if you use npm
npm i -D @swc/core

# if you use yarn
yarn add -D @swc/core
```

See [Getting Started](/docs/getting-started.md) for more details.

## What's included in SWC 1.0?

Swc implements almost all babel plugins. As of 1.0.0, swc can understand various dialects of ecmascript and compiles them into es5.

### ECMAScript 2019 support

`.swcrc`:

```json
{
  "jsc": {
    "parser": {
      "syntax": "ecmascript"
    }
  }
}
```

### React (with jsx)

`.swcrc`:

```json
{
  "jsc": {
    "parser": {
      "syntax": "ecmascript",
      "jsx": true
    }
  }
}
```

### TypeScript support

Swc can also compile typescript / tsx to ecmascript. Note that it does not type-check at the time of writing. Type checking is tracked at [#126](https://github.com/swc-project/swc/issues/126).

`.swcrc`:

```json
{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false
    }
  }
}
```

See [docs](/docs/configuration/swcrc.md) for more details.

### Various Transforms

- es3

  - member-expression-literals
  - property-literals
  - reserved-words

- es2015

  - arrow-functions
  - block-scoped-functions
  - block-scoping
  - classes
  - computed-properties
  - destructuring
  - duplicate-keys
  - for-of
  - function-name
  - instanceof
  - literals
  - new-target
  - parameters
  - shorthand-properties
  - spread
  - sticky regex (`y` flag)
  - template-literals
  - typeof-symbol

- es2016

  - exponentiation-operator

- es2017

  - async-to-generator

- es2018

  - object-rest-spread

- react
  - jsx

## Migrating from Babel

### @babel/core

Run `npm i --save-dev @swc/core` or `yarn add --dev @swc/core`.

Swc enables all passes by default. So if you are using only standard ecmascript, you can just delete `.babelrc` and change `babel.transform()` to `swc.transform()`.

See [usage docs](/docs/usage/core.md) and [migration docs](/docs/migrating-from-babel.md) for more details.
Also note that swc does not support custom plugin yet.

### @babel/cli

Run `npm i --save-dev @swc/core @swc/cli` or `yarn add --dev @swc/core @swc/cli` to install. CLI apis of `@swc/cli` is almost equivalent to it of `@babel/cli`. So if you are using standard ecmascript, you can just replace `npx babel` to `npx swc`. If it results in an error, please [report an error][issues].

See [usage docs](/docs/usage/cli.md) and [migration docs](/docs/migrating-from-babel.md) for more details. Also note that swc does not support custom plugins yet.

[issues]: https://github.com/swc-project/swc/issues



---
url: /index.md
---

# SWC


Rust-based platform for the Web

SWC is an extensible Rust-based platform for the next generation of fast developer tools. It's used by tools like Next.js, Parcel, and Deno, as well as companies like Vercel, ByteDance, Tencent, Shopify, Trip.com, and [more](/docs/customers.md).

SWC can be used for both compilation and bundling. For compilation, it takes JavaScript / TypeScript files using modern JavaScript features and outputs valid code that is supported by all major browsers.


🏎

SWC is <strong>20x faster than Babel</strong> on a single thread and <strong>70x faster</strong> on four cores.


[Get Started](/docs/getting-started.md) · [Playground](/playground/index.md) · [Rustdocs](https://rustdoc.swc.rs/swc/) · [GitHub Repository](https://github.com/swc-project/swc) · [Discord](https://discord.gg/GnHbXTdZz6) · [Donate](https://opencollective.com/swc)

## Overview

SWC can be downloaded and used as a pre-built binary, or built from source. Currently, the following binaries are provided:

- Mac (Apple Silicon)
- Mac (x64)
- Linux (x86\_64)
- Linux (aarch64)
- Linux (armv7)
- Alpine Linux (also install `@swc/core-linux-musl`)
- Android (aarch64)
- Windows (win32-x64)
- Windows (ia32)

#### Download prebuilt binaries


```sh [pnpm]
pnpm add -D @swc/cli @swc/core
```

```sh [npm]
npm i -D @swc/cli @swc/core
```

```sh [yarn]
yarn add -D @swc/cli @swc/core
```

#### Transpile JavaScript file and emit to stdout

```bash
npx swc ./file.js
```

## Features

SWC is designed to be extensible. Currently, there is support for:

- Compilation
- Minification
- Transforming with WebAssembly
- Usage inside webpack and Rspack (`swc-loader`)
- Improving Jest performance (`@swc/jest`)
- Custom Plugins

[Learn more](/docs/getting-started.md).

## Community


![stars](https://badgen.net/github/stars/swc-project/swc)![downloads](https://badgen.net/npm/dw/@swc/core?label=downloads%20(@swc/core))![downloads](https://badgen.net/npm/dw/@swc/helpers?label=downloads%20(3rd%20party))

SWC is created by [kdy1](https://github.com/kdy1).
Follow [@kdy1dev](https://twitter.com/kdy1dev) on Twitter for future project updates.

Feel free to join the [discussions on GitHub](https://github.com/swc-project/swc/discussions) or [Discord](https://discord.gg/GnHbXTdZz6)!