| 1 | + Scenario why need
|
| 2 | + Two kind deadcode
|
| 3 | + Conclution
|
| 4 |
|
| 5 | ## How to detect deadcode via webpack
|
| 6 |
|
| 7 | ### Scenario
|
| 8 |
|
| 9 | In the last few years, there are a lot of tools which help us split our codebase into small parts and bundle them later (for example: webpack, rollup, brunch ...) Everything has its own cost. In this case, it seems that we will have bunch of files which are not used anymore. The reason might come from:
|
| 10 | + We refactor but forgeting to remove old files/functions.
|
| 11 | + We change a flow, that code related to old features still be there.
|
| 12 |
|
| 13 | Currently, I use webpack as my module bundler. At first, everything is under my control but my codebase gradually becomes biger and the scenario above happens. Luckily, webpack supports us "a way" to detect that problem.
|
| 14 |
|
| 15 | ### Approaches in webpack
|
| 16 |
|
| 17 | In my opinion, there are two kinds of deadcode and with each kind of deadcode, I will demonstrate how to detect in webpack:
|
| 18 | + Unused files
|
| 19 | + Unused exports in used files
|
| 20 |
|
| 21 | #### Unused files
|
| 22 |
|
| 23 | ```
|
| 24 | app
|
| 25 | ├── config
|
| 26 | │ └── routes.js
|
| 27 | ├── screens
|
| 28 | │ └── App
|
| 29 | │ ├── screens
|
| 30 | │ │ ├── Admin
|
| 31 | │ │ │ ├── screens
|
| 32 | ```
|
| 33 |
|
| 34 | The image below is an output when running webpack with my plugin
|
| 35 | 
|
| 36 |
|