When it comes to building good quality software, dead code can be one out of a thousand problems that you need to think about.
Still, it’s a problem you don’t want to forget about for later.
Why is it essential to remove your dead code from front end projects?
If you let dead code sit around without proactively removing it, it will make your software:
Simply put, detecting and removing dead code is a strategic piece of the software process that any technical leader needs to be aware of to manage.
So, how can you detect and remove dead code in a web project?
Having a variety of tools to find and eliminate dead code is a critical part of the long term process of building and maintaining the best digital products.
We recommend using ESLint, Webpack, TypeScript, and more to detect and remove dead code as well as utilizing Depcheck to remove unused dependencies.
Here’s a little bit about each of these tools:
ESLint is perhaps the most widely used JavaScript lint. Among many other useful things,
ESLint allows us to detect unused variables in our files with its aptly named 'no-unused-vars' rule. It can tell us 2 things:
1. If we have declared a variable that is not used elsewhere in the file.
2. If there are unused arguments in our functions.
But ESLint can't solve every dead code problem. Why? -- Even if a variable or function is not used within the file, as long as it is exported, it is no longer considered unused. We can continue using our linter and take advantage of a plugin called 'eslint-plugin-import' and, more specifically, its rule 'no-unused-modules', which allows us to detect both modules without exports, as well as exports that are not imported in other modules. To set it up, install it and then add the plugin and the rule to the ESLint configuration file.
Webpack will automatically attempt to remove unused code in the bundle it produces. There is a handy plugin to help us detect unused files and exports in our code in the process of writing it — 'webpack-deadcode-plugin'.
But this has its limitations as well...
1. The tool’s output in the terminal can get lost or be difficult to parse, depending on other outputs shown in the same place. This can make it inconvenient to use.
2. It might be slightly more difficult to include it in your CI pipeline. The reason is that the plugin will report unused files and unused exports into your terminal but those are not part of your webpack build process, therefore, it will not fail your build.
3. The plugin’s output might be incorrect when using it in a TypeScript project.
You can configure TypeScript in a way that doesn’t allow for unused local variables and function parameters. This is similar to the ESLint rule above. Note that the script above will detect unused exports, even if they are used internally within the module.
Of the presented options, TypeScript can arguably enforce dead code detection in the strictest way. So, if you are working on a TypeScript project, using Typescript-specific tooling — including the compile options in’ tsconfig’ , ‘@typescript-eslint/eslint-plugin’ (to combine with ESLint) and ‘ts-prune’ — is often going to be the optimal approach.
Everyone has the ability to do this, many choose not to.
On the topic of dead code, let's also address unused dependencies. These can be expensive, and take up space that would be better appropriated for something more valuable.
For such a situation, we can use depcheck, a tool for analyzing the dependencies in a project. Depcheck can tell us three things:
You’ll go ahead and install depcheck with ‘npm install -g depcheck’, and run the check with ‘npx depcheck’.
Depcheck uses a ‘special’ component that allows us to recognize those unused dependencies that are outside of our regular import or export flow. This can include dependencies used in configuration files, npm commands, scripts, and more.
For any technical leader managing a digital product, removing dead code is an important issue you need to be aware of.
Left alone, dead code makes your software hard to iterate on, costly to maintain, and with lower performance.
All of these dead code detection methods can be tactical in their own way. They can even be used interchangeably with one another and/or in combination. Of course, choosing your dead code detection setup is heavily dependent on your particular software architecture and toolchain. You might not be using the same detection method for every scenario.
To figure out the most efficient solution for your digital product, you want a partner that can help build you software that manages dead code over time and helps keep you focused on building a high quality product that is easy to maintain and less costly to operate.
If you’re looking for a partner in building high quality, maintainable software that can scale, contact us today.
