Babel config js где находится

Конфигурирование Babel

Babel автоматически конфигурируется для всех файлов .js и .jsx через babel-loader с благоразумными значениями по умолчанию (например, с @babel/preset-env и @babel/preset-react , по запросу).

Вам нужно ещё больше расширить конфигурацию Babel? Самый лёгкий способ сделать это — через configureBabel() :

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// webpack.config.js // . Encore // . .configureBabel(function(babelConfig) < // добавить дополнительные пресеты babelConfig.presets.push('@babel/preset-flow'); // по умолчанию плагины не добавляются, но вы можете их добавить babelConfig.plugins.push('styled-jsx/babel'); >, < // node_modules не обрабатывается через Babel по умолчанию, // но вы можете позволить обработку каких-то конкретных модулей includeNodeModules: ['foundation-sites'], // или полностью контролировать правило исключения (заметьте, что вы не // можете использовать "includeNodeModules" и "exclude" одновременно) exclude: /bower_components/ >) ;

Конфигурация целей браузера

Пресет @babel/preset-env переписывает ваш JavaScript, чтобы финальный синтаксис работал в любом браузере, который вы захотите. Чтобы сконфигурировать браузеры, которые вам нужно поддерживать, см. PostCSS и автоматическое добавление префиксов (postcss-loader).

После изменения вашей конфигурации «browserslist», вам понадобится вручную удалить каталог кеша babel:

# В Unix запустите эту команду. В Windows, очистите этот каталог вручную $ rm -rf node_modules/.cache/babel-loader/

Создание файла .babelrc

Вместо того, чтобы вызывать configureBabel() , вы можете создать файл .babelrc в корне вашего проекта. Это более «стандартный» способ конфигурации Babel, но у него есть недостатки: как только появляется файл .babelrc , Encore больше не может добавлять никакую конфигурацию Babel для вас. Например, если вы вызовете Encore.enableReactPreset() , предустановка react не будет автоматически добавлена в Babel: вы должны будете добавить её сами в .babelrc .

Как только файл .babelrc будет существовать, он будет главенствовать над конфигурацией Babel, добавленной Encore.

Symfony is a trademark of Symfony SAS. Переклад — Playtini. UA RU RU EN

Config Files

Babel имеет два параллельных формата файла конфигурации, которые можно использовать вместе или по отдельности.

• Project-wide configuration
  • Файлы babel.config.* со следующими расширениями: .json , .js , .cjs , .mjs , .cts .
  • Файлы .babelrc.* со следующими расширениями: .json , .js , .cjs , .mjs , .cts .
  • Файл .babelrc без расширения.
  • Файлы package.json с ключом «babel» .

  Project-wide configuration​

  Новое в Babel 7.x, Babel имеет концепцию каталога «root» , который по умолчанию является текущим рабочим каталогом. Для конфигурации всего проекта Babel будет автоматически искать файл babel.config.json или эквивалентный файл с использованием supported extensions в этом корневом каталоге. Кроме того, пользователи могут использовать явное значение «configFile» , чтобы переопределить поведение поиска файла конфигурации по умолчанию.

  Поскольку config files для всего проекта отделен от физического местоположения файла конфигурации, они могут быть идеальными для конфигурации, которая должна применяться широко, даже позволяя легко применять плагины и предустановки к файлам в node_modules или в пакетах с символическими ссылками, которые традиционно было довольно сложно настроить в Babel 6.x..

  Основным недостатком этой общепроектной конфигурации является то, что, поскольку она зависит от рабочего каталога, ее использование в монорепозиториях может быть более болезненным, если рабочий каталог не является корнем монорепозитория. См. документацию monorepo для примеров использования config files в этом контексте.

  Конфигурации всего проекта также можно отключить, установив для «configFile» значение false .

  File-relative configuration​

  Babel загружает файлы .babelrc.json или эквивалентный файл с использованием supported extensions путем поиска в структуре каталогов, начиная с компилируемого «filename» (ограничено предостережениями below).). Это может быть полезным, поскольку позволяет создавать независимые конфигурации для подразделов пакета. также можно выполнить через «overrides» .

  Есть несколько крайних случаев, которые следует учитывать при использовании файловой конфигурации:

  • Поиск прекратится, как только будет найден каталог, содержащий package.json , поэтому относительная конфигурация применяется только в пределах одного пакета.
  • Компилируемый «filename» должен находиться внутри пакетов «babelrcRoots» , иначе поиск будет полностью пропущен.

  Эти предостережения означают, что:

  • Файлы .babelrc.json применяются только к файлам в собственном пакете.
  • Файлы .babelrc.json в пакетах, которые не являются «корневыми» Babel, игнорируются, если вы не выберете «babelrcRoots» .

  См. документацию monorepo для получения дополнительной информации о настройке монорепозиториев с большим количеством пакетов. Файловые конфигурации также можно отключить, установив для «babelrc» значение false .

  6.x против 7.x .babelrc с загрузкой ​

  Пользователи, перешедшие с версии Babel 6.x, скорее всего, столкнутся с этими двумя крайними случаями, которые появились в версии Babel 7.x.. Эти два ограничения были добавлены в Babel 6.x для устранения обычных футганов:

  • Файлы .babelrc применялись к зависимостям node_modules , часто неожиданно.
  • Файлы .babelrc не удалось применить к символической ссылке node_modules , когда люди ожидали, что они будут вести себя как обычные зависимости.
  • Файлы .babelrc в зависимостях node_modules будут обнаружены, даже несмотря на то, что плагины и пресеты внутри них, как правило, не установлены и даже могут быть недействительны в версии Babel, компилирующей файл.

  Эти случаи в первую очередь вызовут проблемы у пользователей со структурой монорепозитория, потому что если у вас есть

  .babelrc packages/ mod1/ package.json src/index.js mod2/ package.json src/index.js

  теперь конфигурация будет полностью проигнорирована, поскольку она находится за пределами пакета.

  Одной из альтернатив может быть создание .babelrc в каждом подпакете, который использует «extends» в качестве

   "extends": "../../.babelrc" >

  К сожалению, этот подход может быть немного повторяющимся, и в зависимости от того, как используется Babel, может потребоваться установка «babelrcRoots» .

  Учитывая это, может быть более желательным переименовать .babelrc в project-wide «babel.config.json» . Как упоминалось выше в разделе, посвященном всему проекту, для этого может потребоваться явная установка «configFile» , поскольку Babel не найдет файл конфигурации, если рабочий каталог неверен.

  Поддерживаемые расширения файлов ​

  Babel можно настроить, используя любое расширение файла, изначально поддерживаемое Node.js,, как указано в разделе Configuration File Types :

  • babel.config.json и .babelrc.json анализируются как JSON5 и должны содержать объект, соответствующий формату options , который принимает Babel. Они поддерживаются начиная с v7.7.0 . Мы рекомендуем использовать этот тип файла везде, где это возможно: JS config files удобен, если у вас есть сложная конфигурация, которая является условной или иным образом вычисляется во время сборки. Однако недостатком является то, что конфигурации JS менее поддаются анализу static и, следовательно, отрицательно влияют на кешируемость, линтинг, автозаполнение IDE и т. д. огромная победа в производительности сборки.
  • babel.config.cjs и .babelrc.cjs позволяют определить вашу конфигурацию как CommonJS, с помощью module.exports . Они поддерживаются начиная с версии v7.7.0 .
  • babel.config.mjs и .babelrc.mjs используют родные модули ECMAScript. Они поддерживаются Node.js 13.2+ (или более старые версии через —experimental-modules flag)., пожалуйста, помните, что нативные модули ECMAScript асинхронны (поэтому import() всегда возвращает promise!): по этой причине, .mjs config files, когда они вызывали Z12491. 19t.
  • babel.config.js и .babelrc.js ведут себя как эквиваленты .mjs , когда ваш файл package.json содержит параметр «type»: «module» , в остальном они точно такие же, как файлы .cjs .
  • babel.config.cts и .babelrc.cts позволяют определить вашу конфигурацию как Typescript + CommonJS.. Необходимо либо установить @babel/preset-typescript , либо запустить Babel с помощью ts-node .

  �� Этот функционал является экспериментальным. Пока нельзя использовать файлы babel.config.ts и babel.config.mts , ожидается стабилизация загрузчика Node.js ESM API.

  Файлы конфигурации JavaScript могут либо экспортировать объект, либо функцию, которая при вызове возвращает сгенерированную конфигурацию. Конфигурации, возвращающие функции, получают несколько особых полномочий, потому что они могут получить доступ к API, предоставленному самим Babel. См. Config Function API для получения дополнительной информации.

  Из соображений совместимости .babelrc является псевдонимом .babelrc.json .

  Monorepos​

  Репозитории со структурой монорепозитория обычно содержат много пакетов, а это означает, что они часто сталкиваются с предостережениями, упомянутыми в file-relative configuration , и загрузкой файла конфигурации в целом. Этот раздел призван помочь пользователям понять, как настроить монорепозиторий.

  При настройке монорепозитория главное, что нужно понимать, это то, что Babel рассматривает ваш рабочий каталог как свой логический «root» , что вызывает проблемы, если вы хотите запускать инструменты Babel в определенном подпакете без применения Babel к репозиторию в целом.

  Отдельно также важно решить, хотите ли вы использовать файлы .babelrc.json или только центральный babel.config.json . Файлы .babelrc.json не требуются для конкретной конфигурации подпапок, как это было в Babel 6, поэтому часто они не нужны в Babel 7 в пользу babel.config.json .

  Корневой файл babel.config.json ​

  Первым шагом в любой структуре монорепозитория должно быть создание файла babel.config.json в корне репозитория. Это устанавливает основную концепцию Babel базового каталога вашего репозитория. Даже если вы хотите использовать файлы .babelrc.json для настройки каждого отдельного пакета, важно иметь место для параметров уровня репо.

  Часто вы можете поместить всю конфигурацию вашего репо в корень babel.config.json . С помощью «overrides» вы можете легко указать конфигурацию, которая применяется только к определенным подпапкам вашего репозитория, что часто может быть проще, чем создавать множество файлов .babelrc.json в репозитории.

  Первая проблема, с которой вы, вероятно, столкнетесь, заключается в том, что по умолчанию Babel ожидает загрузки файлов babel.config.json из каталога, установленного как его «root» , что означает, что если вы создадите babel.config.json , но запустите Babel внутри отдельного пакета, например

  cd packages/some-package; babel src -d dist

  «root» Babel, используемый в этом контексте, не является корнем вашего монорепозитория, и он не сможет найти файл babel.config.json .

  Если все ваши сценарии сборки выполняются относительно корня вашего репозитория, все уже должно работать, но если вы запускаете процесс компиляции Babel из подпакета, вам нужно указать Babel, где искать конфигурацию. Есть несколько способов сделать это, но рекомендуемым способом является вариант «rootMode» с «upward» , который заставит Babel искать из рабочего каталога вверх ваш файл babel.config.json и будет использовать его местоположение в качестве значения «root» .

  Один полезный способ проверить, обнаруживается ли ваша конфигурация, — поместить в нее вызов console.log() , если это файл babel.config.json JavaScript: журнал будет выполняться при первой загрузке Babel.

  Способ установки этого значения зависит от проекта, но вот несколько примеров:

  CLI​

  babel --root-mode upward src -d lib

  When to use babel.config.js and .babelrc

  I was learning Babel and wanted to learn how to configure Babel. I found two ways to configure Babel: by creating babel.config.js and .babelrc file. Under what circumstances should we prefer one config file over the other?

  7,231 3 3 gold badges 35 35 silver badges 60 60 bronze badges
  asked Feb 18, 2020 at 19:45
  899 1 1 gold badge 5 5 silver badges 8 8 bronze badges

  4 Answers 4

  Babel has two parallel config file formats which can be used together, or independently.

  Project-wide configuration babel.config.json files, with the different extensions File-relative configuration .babelrc.json files, with the different extensions package.json files with a "babel" key 

  Babel loads .babelrc.json files, or an equivalent one using the supported extensions, by searching up the directory structure starting from the «filename» being compiled

  Given that information

  .babelrc would be useful if you want to run certain transformations / plugins on a subset of files /directories. Maybe you have 3rd party libraries that you don’t want to be transformed/changed by babel.

  babel.config.json is useful if you have multiple packages (ie multiple package.json) directories in your project that utilize a single babel config. This is less common.

  If your question is about file extensions (ie .js vs .json ) with respect to babel configurations

  Using .js exposes a babel config api.

  Keep in mind this increases complexity with regards to caching, most of the time it’s best to use .json static configurations

  Configure Babel

  Babel can be configured! Many other tools have similar configs: ESLint ( .eslintrc ), Prettier ( .prettierrc ).

  All Babel API options are allowed. However, if the option requires JavaScript, you may want to use a JavaScript configuration file.

  What’s your use case?​

  • You are using a monorepo?
  • You want to compile node_modules ?
  • You have a configuration that only applies to a single part of your project?
  • Guy Fieri is your hero?

  babel.config.json ​

  Create a file called babel.config.json with the following content at the root of your project (where the package.json is).

  babel.config.json

    "presets": [. ], "plugins": [. ] > 

  Check out the babel.config.json documentation to see more configuration options.

  .babelrc.json ​

  Create a file called .babelrc.json with the following content in your project.

  .babelrc.json

    "presets": [. ], "plugins": [. ] > 

  Check out the .babelrc documentation to see more configuration options.

  package.json ​

  Alternatively, you can choose to specify your .babelrc.json config from within package.json using the babel key like so:

  package.json

    "name": "my-package", "version": "1.0.0", "babel":   "presets": [ . ], "plugins": [ . ], > > 

  JavaScript configuration files​

  You can also write babel.config.js (like we’re doing), and .babelrc.js files using JavaScript:

  babel.config.js

  module.exports = function (api)   api.cache(true);  const presets = [ . ]; const plugins = [ . ];  return   presets,  plugins >; > 

  You are allowed to access any Node.js APIs, for example a dynamic configuration based on the process environment:

  babel.config.js

  module.exports = function (api)   api.cache(true);  const presets = [ . ]; const plugins = [ . ];  if (process.env["ENV"] === "prod")   plugins.push(. ); >  return   presets,  plugins >; > 

  You can read more about JavaScript configuration files in the dedicated documentation

  Using the CLI ( @babel/cli )​

  babel --plugins @babel/plugin-transform-arrow-functions script.js 

  Check out the babel-cli documentation to see more configuration options.

  Using the API ( @babel/core )​

  JavaScript

  require("@babel/core").transformSync("code",   plugins: ["@babel/plugin-transform-arrow-functions"], >); 

  Check out the babel-core documentation to see more configuration options.

  Print effective configs​

  You can tell Babel to print effective configs on a given input path

  • Shell
  • powershell

    # *nix or WSL BABEL_SHOW_CONFIG_FOR=./src/myComponent.jsx npm start 

    $env:BABEL_SHOW_CONFIG_FOR = ".srcmyComponent.jsx"; npm start 

  BABEL_SHOW_CONFIG_FOR accepts both absolute and relative file paths. If it is a relative path, it will be resolved from cwd .

  Once Babel processes the input file specified by BABEL_SHOW_CONFIG_FOR , Babel will print effective configs to the console. Here is an example output:

  Babel configs on "/path/to/cwd/src/index.js" (ascending priority): config /path/to/cwd/babel.config.json   "sourceType": "script",  "plugins": [  "@foo/babel-plugin-1"  ],  "extends": "./my-extended.js" > config /path/to/cwd/babel.config.json .env["test"]   "plugins": [  [  "@foo/babel-plugin-3",    "noDocumentAll": true  >,  ]  ] > config /path/to/cwd/babel.config.json .overrides[0]   "test": "src/index.js",  "sourceMaps": true > config /path/to/cwd/.babelrc <> programmatic options from @babel/cli   "sourceFileName": "./src/index.js",  "presets": [  "@babel/preset-env"  ],  "configFile": "./my-config.js",  "caller":  "name": "@babel/cli"  >,  "filename": "./src/index.js" > 

  Babel will print effective config sources ordered by ascending priority. Using the example above, the priority is:

  babel.config.json < .babelrc < programmatic options from @babel/cli

  In other words, babel.config.json is overwritten by .babelrc , and .babelrc is overwritten by programmatic options.

  For each config source, Babel prints applicable config items (e.g. overrides and env ) in the order of ascending priority. Generally each config sources has at least one config item — the root content of configs. If you have configured overrides or env , Babel will not print them in the root, but will instead output a separate config item titled as .overrides[index] , where index is the position of the item. This helps determine whether the item is effective on the input and which configs it will override.

  If your input is ignored by ignore or only , Babel will print that this file is ignored.

  How Babel merges config items​

  Babel’s configuration merging is relatively straightforward. Options will overwrite existing options when they are present and their value is not undefined . There are, however, a few special cases:

  • For assumptions , parserOpts and generatorOpts , objects are merged, rather than replaced.
  • For plugins and presets , they are replaced based on the identity of the plugin/preset object/function itself combined with the name of the entry.

  Option (except plugin/preset) merging​

  As an example, consider a config with:

  JavaScript

    sourceType: "script", assumptions:   setClassFields: true, iterableIsArray: false >, env:   test:   sourceType: "module", assumptions:   iterableIsArray: true, >, > > >; 

  When NODE_ENV is test , the sourceType option will be replaced and the assumptions option will be merged. The effective config is:

  JavaScript

    sourceType: "module", // sourceType: "script" is overwritten assumptions:   setClassFields: true, iterableIsArray: true, // assumptions are merged by Object.assign >, > 

  Plugin/Preset merging​

  As an example, consider a config with:

  JavaScript

  plugins: [ './other', ['./plug',  thing: true, field1: true >] ], overrides: [  plugins: [ ['./plug',  thing: false, field2: true >], ] >] 

  The overrides item will be merged on top of the top-level options. Importantly, the plugins array as a whole doesn’t just replace the top-level one. The merging logic will see that «./plug» is the same plugin in both cases, and < thing: false, field2: true >will replace the original options, resulting in a config as

  JavaScript

  plugins: [ './other', ['./plug',  thing: false, field2: true >], ], 

  Since merging is based on identity + name, it is considered an error to use the same plugin with the same name twice in the same plugins / presets array. For example

  JavaScript

  plugins: ["./plug", "./plug"]; 

  is considered an error, because it’s identical to plugins: [‘./plug’] . Additionally, even

  JavaScript

  plugins: [["./plug",  one: true >], ["./plug",  two: true >]]; 

  is considered an error, because the second one would just always replace the first one.

  If you actually do want to instantiate two separate instances of a plugin, you must assign each one a name to disambiguate them. For example:

  JavaScript

  plugins: [ ["./plug",  one: true >, "first-instance-name"], ["./plug",  two: true >, "second-instance-name"], ]; 

  because each instance has been given a unique name and thus a unique identity.

  Похожие публикации:

  1. Maps app goo gl что это
  2. Из чего состоит кот
  3. Почему не работает секд с
  4. Черный список организаций куда не стоит устраиваться на работу