As your web application project starts to grow, so will your server load times, which is mainly noticeable if you change branches multiple times throughout the day. In this first article of a three-part series on improving the developer experience (DX) on Ember, I will walk through some quick wins you can implement in less than ten minutes to improve your server load time.
Transpile as Little as Possible in Development
Transpiling takes time, and it can be significant when working on a big project. If you have Ember CLI up-to-date, you might have already noted that config/targets.js
only includes old browsers in production or CI. Make sure you are doing so if you have an old project (this is what the file should look like). This also simplifies async
/ await
testing a lot.
While you are at it, make sure you follow a similar strategy in other add-ons you might be using like any CSS transpiler. Refer to its documentation so you can use the right configuration in each case, but if it observes config/targets.js
, you will have to do nothing more.
Disable Hinting and Testing in Development
In your ember-cli-build.js
file, make sure to disable hinting
and tests
in development. To do so, set both options to false
when creating the EmberApp
.
Setting hinting
to false prevents some add-ons from running in a development environment, like linting add-ons. They still run in testing, though; more on this in the next post in the series, where we will remove them completely.
Setting tests
to false prevents Ember CLI from loading the tests tree in development. This change speeds up launching your server, but won’t add a tests
route to run tests in development. You can still use ember tests --serve
to launch them.
In a brand new app, the ember-cli-build.js
would look like this:
"use strict";
const EmberApp = require("ember-cli/lib/broccoli/ember-app");
module.exports = function(defaults) {
let envIsDevelopment = process.env.EMBER_ENV === "development";
let app = new EmberApp(defaults, {
hinting: !envIsDevelopment,
tests: !envIsDevelopment
});
return app.toTree();
};
Configure jsconfig.json Properly
If you are using VSCode or have configured your editor to support jsconfig.json
, adding this file improves the overall experience in your editor.
If you haven’t done so yet, there are lots of tutorials out there for almost any editor: vim, emacs, and many other editors. For example, in VSCode you get absolute auto-imports and can easily navigate to definitions, as it now knows where your files are. Before this change, VSCode would use a relative import that could cause trouble if you were using some code in your app
folder from your tests
folder, due to how Ember defines the project module.
First, you need to know what is the modulePrefix
of your project. You can find it in config/environment.js
and it is usually the project name. Let’s say it is my-app
.
Open or create a jsconfig.json in the root of your project. Make sure the contents look like this:
{
"compilerOptions": {
"target": "es2018",
"experimentalDecorators": true,
"baseUrl": ".",
"paths": {
"my-app/tests/*": ["./tests/*"],
"my-app/*": ["./app/*"]
}
},
"exclude": [
"node_modules",
"bower_components",
"tmp",
"vendor",
".git",
"dist"
]
}
The important parameters are compilerOptions.baseUrl
and compilerOptions.paths
. Don’t forget to change my-app
to your project’s modulePrefix
and the trailing /*
.
After these settings, your editor can autoimport all your files correctly, especially when importing app code from your tests files.
One caveat though, if you have installed Ember CLI in Visual Studio Code directly or indirectly through the Ember extension pack for Visual Studio Code, jsconfig.json
is overwritten each time you launch Visual Studio Code. We’ll see how to prevent this in the second post in the series.
What’s Next?
See you in the second part, where we will improve our tooling a bit by completely removing our hinting add-ons while not only keeping the same functionality, but getting a faster feedback loop from our linters. We will also use that new strategy to prevent our jsconfig.json
from being overwritten by any extension.
DockYard is a digital product agency offering custom software, web, and mobile application development consulting. We provide exceptional professional services in strategy, user experience, digital design, and full stack engineering using Ember.js and Elixir. With a nationwide staff, we’ve got consultants in key markets across the United States, including Seattle, Los Angeles, Denver, Chicago, Austin, Atlanta, New York, and Boston.