@babel/plugin-transform-modules-commonjs

Traduction Bêta Non Officielle

Cette page a été traduite par PageTurner AI (bêta). Non approuvée officiellement par le projet. Vous avez trouvé une erreur ? Signaler un problème →

History

Version	Changes
v7.14.0	Implemented the importInterop option

info

Ce plugin est inclus dans @babel/preset-env sous l'option modules

Ce plugin transforme les modules ECMAScript en CommonJS. Notez que seule la syntaxe des déclarations import/export (import "./mod.js") et des expressions d'import (import('./mod.js')) est transformée, car Babel ne connaît pas les différents algorithmes de résolution entre les implémentations des modules ECMAScript et CommonJS.

Exemple

Entrée

JavaScript

export default 42;

Sortie

JavaScript

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

exports.default = 42;

Installation

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

Utilisation

Avec un fichier de configuration (Recommandé)

JavaScript

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

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

Via CLI

Shell

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

Via l'API Node

JavaScript

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

Options

importInterop

"babel" | "node" | "none", ou (specifier: string, requestingFilename: string | undefined) => "babel" | "node" | "none". Valeur par défaut : "babel".

Les modules CommonJS et ECMAScript ne sont pas entièrement compatibles. Cependant, les compilateurs, bundlers et runtimes JavaScript ont développé différentes stratégies pour les faire fonctionner ensemble aussi bien que possible.

Cette option spécifie quelle stratégie d'interopérabilité Babel doit utiliser. Lorsque c'est une fonction, Babel l'appelle en passant le spécificateur d'import et le chemin de l'importateur. Par exemple, lors de la compilation d'un fichier /full/path/to/foo.js contenant import { a } from 'b', Babel l'appellera avec les paramètres ('b', '/full/path/to/foo.js').

"babel"

Lorsqu'on utilise des exports avec Babel, une propriété non-énumérable __esModule est exportée. Cette propriété est ensuite utilisée pour déterminer si l'import est l'export par défaut ou s'il le contient.

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;

Lorsque cette interopérabilité d'import est utilisée, si les modules importé et importateur sont tous deux compilés avec Babel, ils se comportent comme si aucun n'avait été compilé.

Ce comportement est celui par défaut.

"node"

Lors de l'import de fichiers CommonJS (écrits directement en CommonJS ou générés par un compilateur), Node.js lie toujours l'export default à la valeur de 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;

Ce n'est pas exactement la même chose que ce que fait Node.js, car Babel permet d'accéder à toute propriété de module.exports comme export nommé, tandis que Node.js n'autorise que l'import de propriétés statiquement analysables de module.exports. Cependant, tout import fonctionnant dans Node.js fonctionnera également lorsqu'il est compilé avec Babel en utilisant importInterop: "node".

"none"

Si vous savez que le fichier importé a été transformé par un compilateur qui stocke l'export default dans exports.default (comme Babel), vous pouvez omettre en toute sécurité 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, valeur par défaut : false.

Par défaut, lorsqu'on utilise des exports avec Babel, une propriété non-énumérable __esModule est exportée.

JavaScript

var foo = (exports.foo = 5);

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

attention

Envisagez de migrer vers l'hypothèse de haut niveau enumerableModuleMeta.

babel.config.json

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

Dans les environnements qui ne le supportent pas, vous pouvez activer l'hypothèse enumerableModuleMeta : au lieu d'utiliser Object.defineProperty, une simple assignation sera utilisée.

JavaScript

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

strict

boolean, valeur par défaut : false

Par défaut, lorsqu'on utilise des exports avec Babel, une propriété non-énumérable __esModule est exportée. Dans certains cas, cette propriété est utilisée pour déterminer si l'import est l'export par défaut ou s'il le contient.

JavaScript

var foo = (exports.foo = 5);

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

Pour empêcher l'export de la propriété __esModule, vous pouvez définir l'option strict sur true.

lazy

boolean, Array<string>, ou (string) => boolean, valeur par défaut : false

Modifie les déclarations import compilées par Babel pour qu'elles soient évaluées de manière paresseuse lors de la première utilisation des liaisons importées.

Cela peut améliorer le temps de chargement initial de votre module car l'évaluation des dépendances à l'avance est parfois totalement inutile. C'est particulièrement le cas lors de l'implémentation d'un module de bibliothèque.

La valeur de lazy peut avoir plusieurs effets :

• false - Aucune initialisation différée des modules importés.

• true - N'initialise pas de manière différée les imports locaux ./foo, mais diffère l'initialisation des dépendances foo.

  Les chemins locaux sont plus susceptibles d'avoir des dépendances circulaires, qui pourraient se rompre si chargées de manière différée, donc ils ne sont pas différés par défaut, tandis que les dépendances entre modules indépendants sont rarement cycliques.

• Array<string> - Initialise de manière différée tous les imports dont la source correspond à l'une des chaînes fournies.

• (string) => boolean - Passe une fonction de rappel qui décidera si une chaîne source donnée doit être chargée de manière différée.

Les deux cas où les imports ne peuvent jamais être différés sont :

• import "foo";

  Les imports à effet secondaire sont automatiquement non-différés car leur simple existence signifie qu'il n'y a pas de liaison pour déclencher ultérieurement l'initialisation.

• export * from "foo"

  Réexporter tous les noms nécessite une exécution immédiate car sinon il n'existe aucun moyen de savoir quels noms doivent être exportés.

astuce

Vous pouvez en savoir plus sur la configuration des options de plugin ici

noInterop

boolean, valeur par défaut : false

attention

Déprécié : Utilisez plutôt l'option importInterop.

Lorsqu'elle est définie sur true, cette option a le même comportement que importInterop: "none".

assumptions pertinentes

• enumerableModuleMeta

• noIncompleteNsImportDetection