Detects dead code with confidence via real user monitoring. Finds dead components, routes, helpers, ember-intl translations and whatever your heart desires!

JavaScript is a dynamic language and notoriously hard to statically analyze. While it is easy to detect that a certain file or piece of code is used, detecting that it is not used is really hard. The fact that components and helpers don't get invoked through JavaScript, but Handlebars, and might even have interpolated names, makes this virtually impossible.

False positives are dangerous, as they could lead to deletions that turn up weeks later in production, because of some weird edge-case scenario that has not been accounted for in the analysis.

So instead of doing the hard work ourselves, why don't we let our users do the work in production for us?

ember-dead-code hooks into the central resolver, logs all lookups and periodically reports them to your backend in batches. This technique is called Real User Monitoring.

The longer you collect data, the more confident you can become that your list of code that is in-use is complete. You can then feed this report back into ember-dead-code and let it remove dead code for you.

ember install ember-dead-code

So far this is just an idea and not functional yet. This repo exists so that we can already talk about the concept and review some code.

There's two problems. If your (acceptance) tests do not cover 100 % of your codebase, ember-dead-code will incorrectly report code as dead that is actually in use in production. And if your tests do cover 100 % of your codebase, ember-dead-code can incorrectly report code that is dead in production as still in-use.

You get the most reliable results by monitoring actual production usage.

The ember-resolver is a central piece to every Ember app and a very hot code path. Hooking into it and doing a lot of synchronous work would of course degrade performance noticeably.

This is why we try very hard to make the actual data collection as efficient and lightweight as possible. The only thing we do inside the resolver is pushing the requested lookup specifier, e.g. service:foo, into a shared Set, if natively supported, or plain array otherwise.

We then run a task approx. every n seconds (you can configure that value!) that deduplicates lookup logs and reports them to the backend, when a configurable threshold batch size is reached.

If available, we use requestIdleCallback for this to minimize the noticeable performance impact even further. Otherwise we use later.

YMMV. This depends on the size and behavioral patterns of your user base. We recommend collecting data for at least two weeks, before drawing any conclusions. The longer you wait, the more confident you can be in deleting code.

We also recommend to never stop collecting data. Dead code is an inevitability. As your codebase evolves over time, you will always forget to remove chunks of code. It's nice to have some piece of mind, knowing that your dead code will be reported eventually.