Improving Your DX on Ember, Part 1: Quick Wins

Man on cliff

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.

Newsletter

Stay in the Know

Get the latest news and insights on Elixir, Phoenix, machine learning, product strategy, and more—delivered straight to your inbox.

Narwin holding a press release sheet while opening the DockYard brand kit box