As you refactor and modify applications, it's difficult to manage and keep track of files as they become unused. Keeping this "dead" code around adds noise to your application and reduces clarity. Just as ESLint can tell us when variables become unused, Webpack (with the help of the unused-files-webpack-plugin) can tell us when entire files become unused. First, we'll install the plugin with npm and save it as a devDependency. Next, we'll use npm run scripts to build a new command that will run Webpack with the plugin. Finally, we'll learn how to use Webpack environment variables to conditionally add plugins to your Webpack config. By the end of the lesson, you'll have a useful cli command you can run to check for unused modules in your Webpack build
Instructor: [00:00] Here, we have a repo with a fairly standard setup using npm run scripts to build an application using webpack. If we run npm run build, we see that webpack will output a bundle. Our repo also has ESLint installed, which we can run by using npm run lint. No output means we're lint-free.
[00:23] Here, we have an application with three modules, an index file that imports two other files to do its work. However, as we refactor it, it's easy to miss when pieces of code go unused. Thankfully, if we remove the call to world, ESLint will tell us the world is no longer used.
[00:42] I can verify this by running npm run lint again and seeing that it now errors. If we remove the import, we're now lint-free. Although ESLint can tell us about an unused variable, it doesn't know that world JS was now completely removed from the bundle. We would need webpack to tell us which of our modules are completely unused and aren't being bundled.
[01:06] We'd do this by first installing the unused file's webpack plugin. I'm using the -d command here to save it as a dev dependency. If we go back to package.json, we now see that it's installed. Next, we'll want to create an npm run script that will run this plugin. To do that, we'll create a command called "Check unused."
[01:34] We'll use webpack and environment variables to say, "Unused is true." We'll run webpack in errors-only mode, which will only output something if there's an error. We can now head over to our webpack config to make use of this environment variable.
[01:54] First, we'll import our plugin by requiring it. This is an ES6 module, so we'll need to use the default property. Next, we'll need to switch from exporting an object to exporting a function that returns an object. We'll conditionally use our environment variable to modify the config.
[02:22] We'll say if env and env.unused. Then we'll want to define our plugins, which is an array, to contain a new, unused file plugin, which itself contains options.
[02:41] The first option we'll want to use is fail on unused and set it to true. This will tell webpack to fail the build if there's an unused file rather than simply outputting the list of unused files. Second, we need to specify the patterns of where our source code is located. In this case, it's source*.js.
[03:01] We could save that and then now run npm run check unused. We could see that it caused the webpack build to fail. If we now remove world.js and check unused again, we now see that it passes.
Hi Mike, first of all, thanks for making such a useful lesson! you did a great job indeed. I'd like to know what's different usage ofusing TerserPlugin and unused-files-webpack-plugin?
Thanks! You should be using both together! TerserPlugin will minify your code.... that is, it’ll take your code and rewrite it to the same thing but in a smaller way. This will happen at build time and you should use it when you deploy to production. Your end users get minified code, but your source files stay unminified for development.
With unused-files-webpack-plugin, it’s purpose is to be run during development, to tell you if any of your code is no longer being used. If it reports anything, you can safely delete that file, and that’ll reduce the maintenance burden of the code overall.
That is to say: Terser is for sending smaller payloads to your users, UnusedFiles is for deleting unneeded code from your source files.
Hope that helps!
Thanks Mike, Setting webpack configuration is very troublesome because you don't set it up every day and version 4 updating super fast.