swcrc

Emits cjs-module-lexer annotation cjs-module-lexer is used in Node.js core for detecting the named exports available when importing a CJS module into ESM. swc will emit cjs-module-lexer detectable annotation with this option enabled.

Defaults to true if import_interop is Node, else false

If set to true, dynamic imports will be preserved.

Defaults to swc.

CommonJS modules and ECMAScript modules are not fully compatible. However, compilers, bundlers and JavaScript runtimes developed different strategies to make them work together as well as possible.

• swc (alias: babel)

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.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

function _interop_require_default(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var _foo = _interop_require_default(require("foo"));
var _bar = require("bar");

_foo.default;
_bar.bar;

When this import interop is used, if both the imported and the importer module are compiled with swc they behave as if none of them was compiled.

This is the default behavior.

• node

When importing CommonJS files (either directly written in CommonJS, or generated with a compiler) Node.js always binds the default export to the value of module.exports.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo;
_bar.bar;

This is not exactly the same as what Node.js does since swc allows accessing any property of module.exports as a named export, while Node.js only allows importing statically analyzable properties of module.exports. However, any import working in Node.js will also work when compiled with swc using importInterop: "node".

• none

If you know that the imported file has been transformed with a compiler that stores the default export on exports.default (such as swc or Babel), you can safely omit the _interop_require_default helper.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo.default;
_bar.bar;

Changes Babel's compiled import statements to be lazily evaluated when their imported bindings are used for the first time.

This can improve initial load time of your module because evaluating dependencies up front is sometimes entirely un-necessary. 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.

Defaults to false.

Output extension for generated files.

Defaults to js.

If set to true, This will resolve top .mjs

By default, when using exports with babel 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.

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

Defaults to false.

Emits 'use strict' directive.

Defaults to true.

https://babeljs.io/docs/en/assumptions#arraylikeisiterable

https://babeljs.io/docs/en/assumptions#constantreexports

https://babeljs.io/docs/en/assumptions#constantsuper

https://babeljs.io/docs/en/assumptions#enumerablemodulemeta

https://babeljs.io/docs/en/assumptions#ignorefunctionlength

https://babeljs.io/docs/en/assumptions#ignoretoprimitivehint

https://babeljs.io/docs/en/assumptions#iterableisarray

https://babeljs.io/docs/en/assumptions#mutabletemplateobject

https://babeljs.io/docs/en/assumptions#noclasscalls

https://babeljs.io/docs/en/assumptions#nodocumentall

https://babeljs.io/docs/en/assumptions#noincompletensimportdetection

https://babeljs.io/docs/en/assumptions#nonewarrows

https://babeljs.io/docs/en/assumptions#objectrestnosymbols

https://babeljs.io/docs/en/assumptions#privatefieldsasproperties

https://babeljs.io/docs/en/assumptions#puregetters

https://babeljs.io/docs/en/assumptions#setclassmethods

https://babeljs.io/docs/en/assumptions#setcomputedproperties

https://babeljs.io/docs/en/assumptions#setpublicclassfields

https://babeljs.io/docs/en/assumptions#setspreadproperties

https://babeljs.io/docs/en/assumptions#skipforofiteratorclosing

https://babeljs.io/docs/en/assumptions#superiscallableconstructor

Emits cjs-module-lexer annotation cjs-module-lexer is used in Node.js core for detecting the named exports available when importing a CJS module into ESM. swc will emit cjs-module-lexer detectable annotation with this option enabled.

Defaults to true if import_interop is Node, else false

If set to true, dynamic imports will be preserved.

Defaults to swc.

CommonJS modules and ECMAScript modules are not fully compatible. However, compilers, bundlers and JavaScript runtimes developed different strategies to make them work together as well as possible.

• swc (alias: babel)

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.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

function _interop_require_default(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var _foo = _interop_require_default(require("foo"));
var _bar = require("bar");

_foo.default;
_bar.bar;

When this import interop is used, if both the imported and the importer module are compiled with swc they behave as if none of them was compiled.

This is the default behavior.

• node

When importing CommonJS files (either directly written in CommonJS, or generated with a compiler) Node.js always binds the default export to the value of module.exports.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo;
_bar.bar;

This is not exactly the same as what Node.js does since swc allows accessing any property of module.exports as a named export, while Node.js only allows importing statically analyzable properties of module.exports. However, any import working in Node.js will also work when compiled with swc using importInterop: "node".

• none

If you know that the imported file has been transformed with a compiler that stores the default export on exports.default (such as swc or Babel), you can safely omit the _interop_require_default helper.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo.default;
_bar.bar;

Changes Babel's compiled import statements to be lazily evaluated when their imported bindings are used for the first time.

This can improve initial load time of your module because evaluating dependencies up front is sometimes entirely un-necessary. 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.

Defaults to false.

Output extension for generated files.

Defaults to js.

If set to true, This will resolve top .mjs

By default, when using exports with babel 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.

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

Defaults to false.

Emits 'use strict' directive.

Defaults to true.

Transpiles the broken syntax to the closest non-broken modern syntax

Defaults to false.

The version of the used core js.

Enable all transforms

Emits cjs-module-lexer annotation cjs-module-lexer is used in Node.js core for detecting the named exports available when importing a CJS module into ESM. swc will emit cjs-module-lexer detectable annotation with this option enabled.

Defaults to true if import_interop is Node, else false

If set to true, dynamic imports will be preserved.

Defaults to swc.

CommonJS modules and ECMAScript modules are not fully compatible. However, compilers, bundlers and JavaScript runtimes developed different strategies to make them work together as well as possible.

• swc (alias: babel)

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.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

function _interop_require_default(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var _foo = _interop_require_default(require("foo"));
var _bar = require("bar");

_foo.default;
_bar.bar;

When this import interop is used, if both the imported and the importer module are compiled with swc they behave as if none of them was compiled.

This is the default behavior.

• node

When importing CommonJS files (either directly written in CommonJS, or generated with a compiler) Node.js always binds the default export to the value of module.exports.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo;
_bar.bar;

This is not exactly the same as what Node.js does since swc allows accessing any property of module.exports as a named export, while Node.js only allows importing statically analyzable properties of module.exports. However, any import working in Node.js will also work when compiled with swc using importInterop: "node".

• none

If you know that the imported file has been transformed with a compiler that stores the default export on exports.default (such as swc or Babel), you can safely omit the _interop_require_default helper.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo.default;
_bar.bar;

Changes Babel's compiled import statements to be lazily evaluated when their imported bindings are used for the first time.

This can improve initial load time of your module because evaluating dependencies up front is sometimes entirely un-necessary. 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.

Defaults to false.

Output extension for generated files.

Defaults to js.

If set to true, This will resolve top .mjs

By default, when using exports with babel 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.

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

Defaults to false.

Emits 'use strict' directive.

Defaults to true.

Defaults to false

Defaults to false

Defaults to false

Defaults to false

Defaults to false

Defaults to false

Defaults to false

Defaults to false

Defaults to false.

Names of environment variables that should be inlined with the value of corresponding env during build.

Defaults to ["NODE_ENV", "SWC_ENV"]

Replaces typeof calls for passed variables with corresponding value

e.g. { window: 'object' }

Global variables that should be inlined with passed value.

e.g. { __DEBUG__: true }

Currently noop.

Currently noop.

Currently noop.

• false: removes all comments
• 'some': preserves some comments
• 'all': preserves all comments
• { regex: string }: preserves comments that match the regex

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

Currently noop.

This is experimental, and can be removed without a major version bump.

Use @swc/helpers instead of inline helpers.

Keep class names.

Options for transform.

Emits cjs-module-lexer annotation cjs-module-lexer is used in Node.js core for detecting the named exports available when importing a CJS module into ESM. swc will emit cjs-module-lexer detectable annotation with this option enabled.

Defaults to true if import_interop is Node, else false

If set to true, dynamic imports will be preserved.

Defaults to swc.

CommonJS modules and ECMAScript modules are not fully compatible. However, compilers, bundlers and JavaScript runtimes developed different strategies to make them work together as well as possible.

• swc (alias: babel)

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.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

function _interop_require_default(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var _foo = _interop_require_default(require("foo"));
var _bar = require("bar");

_foo.default;
_bar.bar;

When this import interop is used, if both the imported and the importer module are compiled with swc they behave as if none of them was compiled.

This is the default behavior.

• node

When importing CommonJS files (either directly written in CommonJS, or generated with a compiler) Node.js always binds the default export to the value of module.exports.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo;
_bar.bar;

This is not exactly the same as what Node.js does since swc allows accessing any property of module.exports as a named export, while Node.js only allows importing statically analyzable properties of module.exports. However, any import working in Node.js will also work when compiled with swc using importInterop: "node".

• none

If you know that the imported file has been transformed with a compiler that stores the default export on exports.default (such as swc or Babel), you can safely omit the _interop_require_default helper.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo.default;
_bar.bar;

Changes Babel's compiled import statements to be lazily evaluated when their imported bindings are used for the first time.

This can improve initial load time of your module because evaluating dependencies up front is sometimes entirely un-necessary. 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.

Defaults to false.

Output extension for generated files.

Defaults to js.

If set to true, This will resolve top .mjs

By default, when using exports with babel 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.

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

Defaults to false.

Emits 'use strict' directive.

Defaults to true.

Options for inline-global pass.

Toggles plugins that aid in development, such as

Declares the module specifier to be used for importing the jsx and jsxs factory functions when using runtime 'automatic'

Replace the function used when compiling JSX expressions.

Defaults to React.createElement.

Replace the component used when compiling JSX fragments.

Defaults to React.Fragment

Enable fast refresh feature for React app

Decides which runtime to use when transforming JSX.

• "automatic" - Automatically imports the functions that JSX transpiles to. This is the modern approach introduced in React 17+ that eliminates the need to manually import React in every file that uses JSX.
• "classic" - Uses the traditional JSX transform that relies on React.createElement calls. Requires React to be in scope, which was the standard behavior before React 17.
• "preserve" - Leaves JSX syntax unchanged without transforming it.

Toggles whether or not to throw an error if a 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.

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

Pass true to not mangle class names.

Pass true to not mangle function names.

Pass true to not mangle private props.

Pass true to mangle names declared in the top level scope.

• import { DEBUG } from '@ember/env-flags';
• import { FEATURE_A, FEATURE_B } from '@ember/features';

See: https://github.com/swc-project/swc/issues/18#issuecomment-466272558

https://swc.rs/docs/configuration/compilation#jsctransformdecoratormetadata

https://swc.rs/docs/configuration/compilation#jsctransformdecoratorversion

https://swc.rs/docs/configuration/compilation#jsctransformlegacydecorator

https://www.typescriptlang.org/tsconfig#useDefineForClassFields

https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax

Defaults to false.

Defaults to false.

Emits cjs-module-lexer annotation cjs-module-lexer is used in Node.js core for detecting the named exports available when importing a CJS module into ESM. swc will emit cjs-module-lexer detectable annotation with this option enabled.

Defaults to true if import_interop is Node, else false

If set to true, dynamic imports will be preserved.

Defaults to swc.

CommonJS modules and ECMAScript modules are not fully compatible. However, compilers, bundlers and JavaScript runtimes developed different strategies to make them work together as well as possible.

• swc (alias: babel)

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.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

function _interop_require_default(obj) {
  return obj && obj.__esModule ? obj : { default: obj };
}

var _foo = _interop_require_default(require("foo"));
var _bar = require("bar");

_foo.default;
_bar.bar;

When this import interop is used, if both the imported and the importer module are compiled with swc they behave as if none of them was compiled.

This is the default behavior.

• node

When importing CommonJS files (either directly written in CommonJS, or generated with a compiler) Node.js always binds the default export to the value of module.exports.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo;
_bar.bar;

This is not exactly the same as what Node.js does since swc allows accessing any property of module.exports as a named export, while Node.js only allows importing statically analyzable properties of module.exports. However, any import working in Node.js will also work when compiled with swc using importInterop: "node".

• none

If you know that the imported file has been transformed with a compiler that stores the default export on exports.default (such as swc or Babel), you can safely omit the _interop_require_default helper.

import foo from "foo";
import { bar } from "bar";
foo;
bar;

// Is compiled to ...

"use strict";

var _foo = require("foo");
var _bar = require("bar");

_foo.default;
_bar.bar;

Changes Babel's compiled import statements to be lazily evaluated when their imported bindings are used for the first time.

This can improve initial load time of your module because evaluating dependencies up front is sometimes entirely un-necessary. 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.

Defaults to false.

Output extension for generated files.

Defaults to js.

If set to true, This will resolve top .mjs

By default, when using exports with babel 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.

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

Defaults to false.

Emits 'use strict' directive.

Defaults to true.