@babel/plugin-transform-modules-commonjs

Traduzione Beta Non Ufficiale

Questa pagina è stata tradotta da PageTurner AI (beta). Non ufficialmente approvata dal progetto. Hai trovato un errore? Segnala problema →

History

Version	Changes
v7.14.0	Implemented the importInterop option

informazioni

Questo plugin è incluso in @babel/preset-env nell'opzione modules

Questo plugin trasforma i moduli ECMAScript in CommonJS. Nota che viene trasformata solo la sintassi delle istruzioni import/export (import "./mod.js") e delle espressioni di importazione (import('./mod.js')), poiché Babel non è a conoscenza dei diversi algoritmi di risoluzione tra le implementazioni dei moduli ECMAScript e CommonJS.

Esempio

In

JavaScript

export default 42;

Out

JavaScript

Object.defineProperty(exports, "__esModule", {
  value: true,
});

exports.default = 42;

Installazione

npm

npm install --save-dev @babel/plugin-transform-modules-commonjs

Yarn

yarn add --dev @babel/plugin-transform-modules-commonjs

pnpm

pnpm add --save-dev @babel/plugin-transform-modules-commonjs

Bun

bun add --dev @babel/plugin-transform-modules-commonjs

Utilizzo

Con un file di configurazione (Consigliato)

JavaScript

// without options
{
  "plugins": ["@babel/plugin-transform-modules-commonjs"]
}

// with options
{
  "plugins": [
    ["@babel/plugin-transform-modules-commonjs", {
      "allowTopLevelThis": true
    }]
  ]
}

Tramite CLI

Shell

babel --plugins @babel/plugin-transform-modules-commonjs script.js

Tramite Node API

JavaScript

require("@babel/core").transformSync("code", {
  plugins: ["@babel/plugin-transform-modules-commonjs"],
});

Opzioni

importInterop

"babel" | "node" | "none", oppure (specifier: string, requestingFilename: string | undefined) => "babel" | "node" | "none". Valore predefinito: "babel".

I moduli CommonJS ed ECMAScript non sono completamente compatibili. Tuttavia, compilatori, bundler e runtime JavaScript hanno sviluppato diverse strategie per farli collaborare nel modo migliore possibile.

Questa opzione specifica quale strategia di interoperabilità Babel deve utilizzare. Quando è una funzione, Babel la chiama passando lo specificatore di importazione e il percorso del file importatore. Ad esempio, durante la compilazione di un file /full/path/to/foo.js contenente import { a } from 'b', Babel chiamerà la funzione con i parametri ('b', '/full/path/to/foo.js').

"babel"

Quando si utilizzano export con Babel, viene esportata una proprietà non enumerabile __esModule. Questa proprietà viene poi utilizzata per determinare se l'importazione è l'export di default o se contiene l'export di default.

JavaScript

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

// Is compiled to ...

"use strict";

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

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

_foo.default;
_bar.bar;

Quando si utilizza questa interoperabilità di importazione, se sia il modulo importato che quello importatore sono compilati con Babel, si comportano come se nessuno dei due fosse stato compilato.

Questo è il comportamento predefinito.

"node"

Quando si importano file CommonJS (scritti direttamente in CommonJS o generati con un compilatore), Node.js associa sempre l'export default al valore di module.exports.

JavaScript

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;

Questo non è esattamente identico a ciò che fa Node.js poiché Babel consente di accedere a qualsiasi proprietà di module.exports come export nominato, mentre Node.js consente solo di importare proprietà staticamente analizzabili di module.exports. Tuttavia, qualsiasi importazione funzionante in Node.js funzionerà anche quando compilata con Babel utilizzando importInterop: "node".

"none"

Se sai che il file importato è stato trasformato con un compilatore che memorizza l'export default in exports.default (come Babel), puoi omettere in sicurezza l'helper _interopRequireDefault.

JavaScript

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;

loose

boolean, predefinito false.

Per impostazione predefinita, quando si utilizzano export con Babel viene esportata una proprietà non enumerabile __esModule.

JavaScript

var foo = (exports.foo = 5);

Object.defineProperty(exports, "__esModule", {
  value: true,
});

attenzione

Considera di migrare all'assunzione di primo livello enumerableModuleMeta.

babel.config.json

{
  "assumptions": {
    "enumerableModuleMeta": true
  }
}

In ambienti che non supportano questa funzionalità, puoi abilitare l'assunzione enumerableModuleMeta: invece di usare Object.defineProperty, verrà utilizzata un'assegnazione diretta.

JavaScript

var foo = (exports.foo = 5);
exports.__esModule = true;

strict

boolean, predefinito false

Per impostazione predefinita, quando si utilizzano export con Babel viene esportata una proprietà non enumerabile __esModule. In alcuni casi questa proprietà viene utilizzata per determinare se l'importazione è l'export di default o se contiene l'export di default.

JavaScript

var foo = (exports.foo = 5);

Object.defineProperty(exports, "__esModule", {
  value: true,
});

Per impedire l'esportazione della proprietà __esModule, puoi impostare l'opzione strict a true.

lazy

boolean, Array<string>, oppure (string) => boolean, predefinito false

Modifica le istruzioni import compilate da Babel affinché vengano valutate in modo lazy quando i loro binding importati vengono utilizzati per la prima volta.

Ciò può migliorare il tempo di caricamento iniziale del modulo perché la valutazione delle dipendenze in anticipo a volte è completamente superflua. Questo è particolarmente vero quando si implementa un modulo libreria.

Il valore di lazy produce alcuni possibili effetti:

• false - Nessuna inizializzazione lazy per qualsiasi modulo importato.

• true - Non inizializza in modo lazy le importazioni locali ./foo, ma applica il lazy-loading alle dipendenze foo.

  I percorsi locali hanno maggiori probabilità di avere dipendenze circolari, che potrebbero rompersi se caricate in modo lazy, quindi non sono lazy per impostazione predefinita, mentre le dipendenze tra moduli indipendenti raramente sono cicliche.

• Array<string> - Inizializza in modo lazy tutte le importazioni la cui sorgente corrisponde a una delle stringhe fornite.

• (string) => boolean - Passa una callback che decide se una determinata stringa sorgente debba essere caricata in modo lazy.

I due casi in cui le importazioni non possono mai essere lazy sono:

• import "foo";

  Le importazioni con effetti collaterali sono automaticamente non-lazy poiché la loro stessa esistenza significa che non c'è alcun binding per avviare successivamente l'inizializzazione.

• export * from "foo"

  La riesportazione di tutti i nomi richiede un'esecuzione immediata perché altrimenti non c'è modo di sapere quali nomi devono essere esportati.

consiglio

Maggiori informazioni sulla configurazione delle opzioni del plugin sono disponibili qui

noInterop

boolean, predefinito false

attenzione

Deprecato: Utilizza invece l'opzione importInterop.

Quando impostato su true, questa opzione ha lo stesso comportamento di importInterop: "none".

assumptions rilevanti

• enumerableModuleMeta

• noIncompleteNsImportDetection