Какую версию JS по умолчанию выводит wp-scripts?

Настройка webpack по умолчанию для wp-scripts находится здесь: node_modules@wordpress\scripts\config

Это содержит следующее:

                            ...( ! hasBabelConfig() && {
                                babelrc: false,
                                configFile: false,
                                presets: [
                                    require.resolve(
                                        '@wordpress/babel-preset-default'
                                    ),
                                ],
                                plugins: [
                                    hasReactFastRefresh &&
                                        require.resolve(
                                            'react-refresh/babel'
                                        ),
                                ].filter( Boolean ),
                            } ),

Это загружает конфигурацию:

\node_modules@wordpress\babel-preset-default\index.js

Этот файл содержит плагины для JSX и Typescript. Он также содержит следующее:

return [ require.resolve( ‘@babel/preset-env’ ), opts ];

и использует этот файл browserlist;

// browserslist-config/index.js
module.exports = [
    '> 1%',
    'last 1 Android versions',
    'last 1 ChromeAndroid versions',
    'last 2 Chrome versions',
    'last 2 Firefox versions',
    'last 2 Safari versions',
    'last 2 iOS versions',
    'last 2 Edge versions',
    'last 2 Opera versions',
];

Так что – это всё? Это то, что wp-scripts поддерживает по умолчанию? (Я понимаю, что это вопрос больше связан с babel, чем с wp-scripts, но, думаю, будет полезно знать ответ на более простой вопрос о wp-scripts – по крайней мере для таких людей, как я).

Browserslist для WordPress

Как вы уже заметили, @wordpress/scripts использует конфигурацию browserslist из пакета @wordpress/browserslist-config – и поэтому движки и функции, которые wp-scripts нацеливается по умолчанию, лучше всего описываются текущими запросами в этом файле.

Эти запросы могут изменяться с течением времени, но хорошая новость в том, что они могут не нуждаться в изменении с заметной частотой. Оставленные без изменений, те же запросы будут приводить к разному результату, подстраиваясь под текущие устройства и браузеры в момент сборки.

Возможно, можно использовать данные и инструменты browserslist/caniuse/MDN, чтобы определить, какая спецификация ECMAScript охватывает все языковые функции, используемые фрагментом кода, нацеливаясь на эти запросы, хотя я не вижу реальной практической пользы в этом. Существуют даже некоторые пакеты, которые утверждают, что напрямую облегчают эту функциональность, такие как browserslist-generator.

Я написал небольшой скрипт против этого пакета из любопытства. Вот его вывод на момент написания:

Информация Browserslist для WordPress
==========================
Browserlist: https://raw.githubusercontent.com/WordPress/gutenberg/refs/heads/trunk/packages/browserslist-config/index.js
Дата: 2024-11-15T21:23:33.384Z
Запросы:
     > 1%
     последние 1 версия Android
     последние 1 версия ChromeAndroid
     последние 2 версии Chrome
     последние 2 версии Firefox
     последние 2 версии Safari
     последние 2 версии iOS
     последние 2 версии Edge
     последние 2 версии Opera
Совместимость ECMAScript: es5
Покрытие аудитории: см. https://browserl.ist/?q=%3E+1%25,%0Alast+1+Android+versions,%0Alast+1+ChromeAndroid+versions,%0Alast+2+Chrome+versions,%0Alast+2+Firefox+versions,%0Alast+2+Safari+versions,%0Alast+2+iOS+versions,%0Alast+2+Edge+versions,%0Alast+2+Opera+versions

Хотя ES5 и ES6/2015 широко считаются общедоступными, я не уверен в этом результате. Кажется маловероятным, что эти запросы приведут к транспиляции до вывода, совместимого с ES5, так как это подразумевает, что более 1% браузеров, используемых сегодня, способны обрабатывать функционал, который 15 лет назад. Но, возможно, это правда, особенно в бизнес-контексте. Утверждаемое покрытие аудитории 85.5% по этим запросам подсказывает мне что-то гораздо более современное – версия ECMAScript за последние несколько лет кажется более вероятной.

Это всё, что я могу предоставить по этому вопросу. Остальная часть этого ответа больше напоминает неуместную запись в блоге.

Педантичность “версии JavaScript”

Или: Как я научился не беспокоиться о версиях и полюбил инструментальные цепочки

Для меня “версия JavaScript” не означает особо много. Существуют версии спецификаций ECMAScript (“ES”), против которых реализуются движки JavaScript, но не редкость, когда движки, реализующие спецификацию ES, пропускают некоторые из функций, которые спецификация определяет. Или они могут реализовать функцию «частично» или интерпретировать неоднозначности иначе, чем другие реализации, в результате чего движок показывает несколько отличающееся поведение.

Кроме того, движки обычно не реализуют поддержку всей спецификации ES сразу – отдельные функции спецификации обычно постепенно вводятся и выпускаются по мере их независимой зрелости. Иногда даже до завершения соответствующей спецификации. И полифилл-скрипты могут использоваться внутри или вместе со скриптом, чтобы обеспечить совместимость с функцией в движках, которые ее иначе не поддерживают.

Таким образом, идентификатор версии ES может иметь совершенно разные значения в зависимости от контекста, в котором он используется. А поскольку как движки, так и скрипты развиваются по более изменчивому расписанию, границы становятся очень размазанными.

Часто говорят, что движок «поддерживает ES X», если он реализует значительное большинство популярных функций этой спецификации. А скрипт может классифицироваться как «нацеленный на» или «совместимый с ES X», если эта спецификация поддерживает все языковые функции, которые использует скрипт. Но поскольку это довольно широкие обобщения, эта информация не особенно полезна для определения того, способен ли какой-либо конкретный версия движка интерпретировать конкретный скрипт.

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

Требования к движку скрипта можно было бы наиболее точно описать довольно длинным списком версий движков JS, которые впервые покрывали полный набор функций, используемый в коде. Или наоборот, можно было бы перечислить каждую современную языковую функцию, от которой он зависит. Но любое из этих описаний будет довольно трудно истолковывать, передавать и поддерживать.

Этот безнадежный жонглирование — примерно то, что разработчики веба испытывали в прежние времена. Это было очень весело. Но сегодня мы можем опираться на инструменты, такие как Babel и browserslist, которые позволяют нам больше сосредоточиться на коде и значительно меньше беспокоиться о версиях языка и совместимости.