At the moment, server-side code is compiled w/ Babel on the fly via @babel/register, while client-side code is compiled via babel-loader. For tests, all code is compiled via babel-jest transformer.
In all cases, the central Babel configuration file is used, which includes @babel/preset-env preset, leveraging the central .browserslistrc configuration file, which only lists browser targets today, regardless of compilation context or environment variables.
This leads to the server-side code being compiled for browser targets, whereas it runs in a Node.js context, which poses multiple issues on server-side code specifically:
performs unnecessary browser-specific transformations, which slows down boot time
over-polyfills the code, which may negatively impact runtime performance
may not perform some Node.js specific necessary transforms, which may lead to bugs that will be exceptionally difficult to debug
Somewhat related to:
At the moment, server-side code is compiled w/ Babel on the fly via
@babel/register
, while client-side code is compiled viababel-loader
. For tests, all code is compiled viababel-jest
transformer.In all cases, the central Babel configuration file is used, which includes
@babel/preset-env
preset, leveraging the central.browserslistrc
configuration file, which only lists browser targets today, regardless of compilation context or environment variables.This leads to the server-side code being compiled for browser targets, whereas it runs in a Node.js context, which poses multiple issues on server-side code specifically:
This can be solved by either:
BROWSERSLIST_ENV
environment variable in.browserslistrc
configuration file for the Node.js processBROWSERSLIST_CONFIG
environment variable` to specify path of another Browserslist configuration file for the Node.js process@babel/register
at runtime in production-like environments (#11626).┆Issue is synchronized with this Jira Task