We have three major language environments in use across our projects:
- In projects such as Clay (and, at the time of writing, the liferay-js-toolkit "develop" branch) we are starting to use TypeScript.
- In projects such as js-themes-toolkit and npm-tools we use vanilla (untranspiled) JavaScript. These are command-line tools and, for consistency, we assume the availability of language features that are available in the version of NodeJS that is used by liferay-portal (currently, v10.15.1).
- In most other projects, including liferay-portal itself, we use Babel; see the following section for a description of which transforms we use.
Our goal in using Babel is to allow developers to write "modern JS" without having to dwell on platform specific limitations. Our main constraint is that we expect the transpiled code to work on all environments defined in the Liferay DXP Compatibility Matrix, which in practice means "modern browsers plus IE 11".
In order to avoid churn, we don't make use of experimental transforms, but rather wait until proposals have reached "stage 4" of the TC39 process before enabling them. In rare cases, we may include stage 3 proposals that are exceptionally useful (eg. we enabled babel-plugin-proposal-class-properties in liferay-npm-scripts because it is so broadly relied upon within the React ecosystem). As seen in this TypeScript issue, in practice, stage 3 proposals are unlikely to change but sometimes they do, so caution is warranted.