|
1 | | -Ember application builds are created by the Ember CLI build pipeline. Just as with your application code, |
2 | | -Ember CLI ships with a sensible set of defaults to compile and bundle the assets that can be deployed |
3 | | -to production. Under the hood, this is accomplished using a series of Broccoli plugins, each of which |
4 | | -can be configured in the `ember-cli-build.js` file at the root of your project. |
5 | | - |
6 | | -Ember CLI uses [Babel.js](https://babeljs.io/) for the compile step in this process. If you've used Babel |
7 | | -before, you know that it comes with a large set of options, including the ability to configure |
8 | | -"targets"; i.e. the environments in which your application is expected to run. |
9 | | -For example, if your application is embedded in an [Electron app](https://www.electronjs.org), |
10 | | -you might only care about compiling for the latest Chromium build. Or if your app targets Enterprise |
11 | | -users, you may need to compile your JavaScript to older syntax that runs in IE11. |
12 | | - |
13 | | -For any of these cases, you can configure `ember build` to do The Right Thing. You can read more about |
14 | | -this in [the Ember CLI Guides](https://cli.emberjs.com/release/advanced-use/build-targets/)! |
| 1 | +By default, Ember apps are built with Vite. The toolchain uses Babel, esbuild, and Rollup so you can write current-generation JavaScript and TypeScript while still allowing your application to work with older browsers. |
| 2 | + |
| 3 | +Rather than always compiling everything down to legacy syntax, Ember determines what—if anything—needs to be transformed based on the browsers you target. With today’s defaults aimed at evergreen browsers, many features (ES modules, classes, arrow functions, async/await, etc.) ship largely as-is. |
| 4 | + |
| 5 | +Why does this matter? Over-transpiling to very old JavaScript increases bundle size, slows parsing, and in some cases can slow down the execution of your JavaScript code. As the Web platform has advanced and percentage of users on legacy browsers have decreased, Ember’s default targets avoid unnecessary transforms to keep apps smaller and faster. |
| 6 | + |
| 7 | +If you need to update the defaults for any reason (i.e. need to target a very legacy browser), you can set the targets for your app and the compiler applies only the minimal transforms and polyfills required for those browsers. |
| 8 | + |
| 9 | +If you open `config/targets.js`, you will find the following code: |
| 10 | + |
| 11 | +```javascript {data-filename=config/targets.js} |
| 12 | +"use strict"; |
| 13 | + |
| 14 | +const browsers = [ |
| 15 | + "last 1 Chrome versions", |
| 16 | + "last 1 Firefox versions", |
| 17 | + "last 1 Safari versions", |
| 18 | +]; |
| 19 | + |
| 20 | +module.exports = { |
| 21 | + browsers, |
| 22 | +}; |
| 23 | +``` |
| 24 | + |
| 25 | +If you inspect your compiled code after running a build with `npm run build`, you'll see that many modern features (like arrow functions and async/await) preserved when your targets support them. |
| 26 | + |
| 27 | +This feature is backed by [Browserslist](https://github.com/ai/browserslist) and [Can I Use](https://caniuse.com/). |
| 28 | +These websites track usage stats of browsers, so you can use complex queries based on the user base of every browser. |
| 29 | + |
| 30 | +If you want to target all browsers with more than a 4% market share in Canada, |
| 31 | +you'd have the following options: |
| 32 | + |
| 33 | +```javascript {data-filename=config/targets.js} |
| 34 | +module.exports = { |
| 35 | + browsers: ["> 4% in CA"], |
| 36 | +}; |
| 37 | +``` |
| 38 | + |
| 39 | +It is very important that you properly configure the targets of your app so you get the smallest and fastest code possible. |
0 commit comments