The default webpack config for wp-scripts is here: node_modules@wordpress\scripts\config
This has this:
...( ! hasBabelConfig() && {
babelrc: false,
configFile: false,
presets: [
require.resolve(
'@wordpress/babel-preset-default'
),
],
plugins: [
hasReactFastRefresh &&
require.resolve(
'react-refresh/babel'
),
].filter( Boolean ),
} ),
This loads a config:
\node_modules@wordpress\babel-preset-default\index.js
This file contains plugins for JSX and Typescript. It also has this:
return [ require.resolve( '@babel/preset-env' ), opts ];
and uses this browserlist file;
// 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',
];
So - is that it? This is what wp-scripts supports by default? (I realise that this is a question more related to babel than wp-scripts but I guess it might be helpful to know the answer to the simpler question about wp-scripts - at least for people like me).
The default webpack config for wp-scripts is here: node_modules@wordpress\scripts\config
This has this:
...( ! hasBabelConfig() && {
babelrc: false,
configFile: false,
presets: [
require.resolve(
'@wordpress/babel-preset-default'
),
],
plugins: [
hasReactFastRefresh &&
require.resolve(
'react-refresh/babel'
),
].filter( Boolean ),
} ),
This loads a config:
\node_modules@wordpress\babel-preset-default\index.js
This file contains plugins for JSX and Typescript. It also has this:
return [ require.resolve( '@babel/preset-env' ), opts ];
and uses this browserlist file;
// 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',
];
So - is that it? This is what wp-scripts supports by default? (I realise that this is a question more related to babel than wp-scripts but I guess it might be helpful to know the answer to the simpler question about wp-scripts - at least for people like me).
As you have noted, @wordpress/scripts utilizes the browserslist configuration from the @wordpress/browserslist-config package - and so the engines and features which wp-scripts targets by default are most aptly described by the current queries in that file.
These may change over time, but the neat thing about these queries is that they may not need to with any notable frequency. Left unchanged, the same queries will result in different output, adjusting for the current device and browser audiences at build time.
It may be possible to use the browserslist/caniuse/MDN data and tools to determine which ECMAScript specification covers all of the language features used by a piece of code while targeting these queries, though I don't feel there's really any practical use in doing so. There are even some packages which allege to directly facilitate this functionality such as browserslist-generator.
I wrote a quick script against that package out of curiosity. This was it's output as of the time of writing:
WordPress Browserlist Info
==========================
Browserlist: https://raw.githubusercontent.com/WordPress/gutenberg/refs/heads/trunk/packages/browserslist-config/index.js
Date: 2024-11-15T21:23:33.384Z
Queries:
> 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
ECMAScript Compatibility: es5
Audience Coverage: see 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
While ES5 and ES6/2015 are widely regarded as globally supported, I am not confident in that result. It seems implausible that these queries would result in transpilation down to ES5-compatible output, as that would imply that more than 1% of browsers in use today are only capable of handling a 15-year-old feature set. But maybe this true, perhaps especially in business contexts. The purported 85.5% audience coverage of those queries suggests to me something much, much more recent - an ECMAScript version from the last few years seems more likely.
That's about as much insight as I can provide. The remainder of this answer is more of a misplaced blog post.
Or: How I Learned to Stop Worrying About Versions and Love the Toolchain
A "JavaScript Version" doesn't mean a whole lot to me. There are versions of the ECMAScript ("ES") specifications which JavaScript engines are implemented against, but it is not uncommon for engines implementing an ES spec to omit some of the features which the spec defines. Or they may implement a feature "partially," or interpret ambiguities differently than other implementors resulting in a somewhat different behavior for an engine.
Engines also don't tend to implement support for an entire ES spec at once - individual features from the spec are usually gradually introduced and released as they independently reach maturity. Sometimes before the corresponding spec is even finalized. And polyfill scripts may be used within or alongside a script in order to shim compatibility for a feature into engines which do not otherwise support it.
All together, an ES version identifier may have wildly different implications depending on the context in which it is used. And both engines and scripts evolving on more of a rolling schedule, the lines become very blurry.
It is often said that an engine "supports ES X" if it implements a substantial majority of the popular features of that spec. And a script might be classified as "targeting" or "compatible with ES X" if that spec supports all of the language features which the script uses. But both being pretty broad generalizations, this information is not especially useful in determining if any particular version of whatever engine is capable of interpreting a particular script.
In practice, the closest thing to an actual "JavaScript version" may be an engine and version identifier, as that effectively and succinctly implies specific implementations of a specific set of language features.
A script's engine requirements could be most accurately described by a considerably lengthy list of JS engine versions which first covered the complete feature set used in the code. Or alternately it could list each contemporary language feature which it depends upon. But either would be quite a nightmare to interpret, convey, and maintain.
This hopeless juggling act is roughly what web devs were subjected to in the before times. It was great fun. But today we get to lean on tooling like Babel and browserslist, enabling us to focus more on the code and worry a whole lot less about language versions and compatibility.