Babel по умолчанию предполагает, что файлы, которые он обрабатывает, являются модулями ES (с использованием import
и export
).Если вы запускаете Babel для вещей в node_modules
(которые, вероятно, являются модулями CommonJS), вам нужно либо сказать Babel обработать все node_modules
как сценарии, либо сказать Babel угадать тип, основываясь на наличии import
и export
.Гадать проще всего, поэтому вы можете добавить
sourceType: "unambiguous"
, а также сказать Бабелу, чтобы он не запускал преобразование usage
для самого core-js
с
ignore: [
/\/core-js/,
],
, потому что в противном случае usage
фактически преобразование будет вставлять ссылки на core-js
в сам , вызывая циклы зависимости.
Таким образом, в вашей конфигурации Babel верхнего уровня, вы должны сделать, например,
{
ignore: [
/\/core-js/,
],
sourceType: "unambiguous",
presets: [
['@babel/preset-env', { modules: false, useBuiltIns: 'usage' }],
],
}
Если вы хотите быть более конкретным в этом вопросе, вы можете также сделать
{
ignore: [
/\/core-js/,
],
presets: [
['@babel/preset-env', { modules: false, useBuiltIns: 'usage' }],
],
overrides: [{
test: "./node_modules",
sourceType: "unambiguous",
}],
}
, чтобы установить флаг только для файлов внутри node_modules
, но, вероятно, это не принесет особой выгоды.
Что касается , почему это исправляет эту ошибку, проблема в том, что, если Бабель считает, что что-то является модулем ES, он вставит import
операторов.Если вы вставите оператор import
в файл, который также использует CommonJS, такие как module.exports
, это означает, что файл теперь будет использовать обе системы модулей в одном файле, что является большой проблемой и вызывает ошибки, которые вы видите.