Extraneous warnings? Here's how to ignore them

Ember's warnings are both useful and important for developers. On our own apps, we like to treat all warnings as errors. This means PRs that add new warning messages (including deprecations) will be rejected.

Treating warnings as errors has not only kept our code up-to-date, but it also prevents scenarios we’ve had in the past where odd test failures and race conditions were ultimately resolved by getting rid of warnings. Treating warnings and deprecations as errors has given me way more confidence that our code works as expected.

Still, there are times where some code will issue a warning that we're ok with. Here's an example of one from ember-test-selectors that I recently came across:

ember-test-selectors could not bind data-test-* properties on
component:hello-world automatically because tagName is empty.

This happens when you try to use a data-test-attribute on a tagless component.

In our own apps, we occasionally do this deliberately because we want to use the data-test-id attribute on an element inside of a tagless component’s template, and we don’t want to change the interface that developers use when setting test ids.

For example, say we have a {{ui-img}} component that has an API similar to an image tag. This component happens to be implemented as a tagless component, because we want to display a skeleton screen while the image is being loading:

// app/components/ui-img.js
Ember.Component.extend({
  tagName: ''
  // ...
})

{{! app/templates/components/ui-img.hbs }}
{{#if isImageLoaded}}
  <img src="..." data-test-id=data-test-id>
{{else}}
  {{skeleton-image}}
{{/if}}

Developers can use this component and pass in a data-test-id, just as if it were a component with a root tag:

{{ui-img src="..." data-test-id="my-logo"}}

and the data-test-id attribute will end up on the element they’d expect.

Doing this causes Ember Test Selectors to log a warning, which fills up our console pretty quickly. Since we're ok with this behavior, we want to deliberately opt-out of this particular warning message. Let me show you how.

We can use the registerWarnHelper in our app.js file to intercept the warning and ignore it:

// app.js
import config from ‘./config/environment’;

// snip

Ember.Debug.registerWarnHandler(function(message, { id }, next) {
  if (id !== 'ember-test-selectors.empty-tag-name') {
    next(...arguments);
  }
});

Since Ember warnings come with a unique string identifier, it's easy for us to catch and ignore them. By not invoking the next callback in registerWarnHelper, the warning will never get logged to the screen.

This is important because it keeps the console clean, which lets us easily notice warnings that we are interested in.

To wrap up, I will note that we very rarely ignore warnings like this. In all my time developing Ember apps, I can count the times I've ignored warnings on one hand. It's important to understand the tradeoffs from opting-out of an addon author's warnings. However, if there is a warning that you have addressed but have a good, defensible reason to ignore, it’s better to hide the clutter from your output than become desensitized to warnings that may in fact be actionable.