Как найти неиспользуемый код в JavaScript-проекте

Начните с автоматического поиска, затем проверьте найденное вручную

Найти неиспользуемый код в JavaScript-проекте можно комбинацией статического анализа, проверки зависимостей и удаления небольшими шагами с обязательным запуском тестов и сборки после каждого изменения. Один инструмент не видит все случаи: неиспользуемые экспорты, файлы, npm-пакеты и локальные переменные требуют разных проверок.

1. Проверьте неиспользуемые переменные и импорты

Первый уровень проверки — линтер. Для проектов с ESLint обычно используют правила, которые обнаруживают неиспользуемые локальные переменные и импорты.

Проверьте, что в конфигурации ESLint включено правило no-unused-vars:

{
  "rules": {
    "no-unused-vars": "error"
  }
}

После этого запустите проверку проекта:

npx eslint .

Такой анализ помогает найти код вроде объявленных переменных, которые нигде не читаются, или импортов, которые больше не нужны после изменений.

2. Найдите неиспользуемые экспорты и файлы

Линтер обычно не определяет, что целый модуль больше нигде не импортируется. Для этого подходят специализированные анализаторы. Один из распространённых вариантов для JavaScript и TypeScript-проектов — Knip.

Установите его в проект как зависимость для разработки:

npm install --save-dev knip

Запустите анализ:

npx knip

Инструмент может показать неиспользуемые файлы, экспорты и зависимости. Перед удалением каждого найденного элемента проверьте, не используется ли он через динамический импорт, регистрацию плагина, конфигурационный файл или внешний интерфейс пакета.

Не удаляйте найденный код автоматически. Статический анализ не всегда видит вызовы через строки, загрузку модулей во время выполнения и использование через внешние системы.

3. Проверьте настройки сборщика

Современные сборщики могут удалять недостижимый код при сборке, но наличие tree shaking не означает, что исходный проект не содержит лишних файлов и зависимостей.

Проверьте, что проект корректно описывает модули. Например, в библиотеках на npm поле sideEffects в package.json влияет на возможность безопасного удаления неиспользуемого кода некоторыми сборщиками.

{
  "sideEffects": false
}

Используйте такое значение только если файлы действительно не содержат побочных эффектов при импорте. Если модуль выполняет действия сразу после загрузки, например регистрирует обработчики или изменяет глобальное состояние, неправильная настройка может изменить поведение приложения.

4. Найдите неиспользуемые npm-зависимости

Удалённый JavaScript-код часто оставляет после себя пакеты, которые больше не нужны. Проверяйте зависимости отдельно от исходников.

Сначала посмотрите текущий список зависимостей:

npm ls --depth=0

Затем используйте анализатор зависимостей, например Knip, чтобы найти пакеты, которые не используются в исходном коде. Найденные зависимости проверяйте перед удалением: некоторые пакеты нужны только для скриптов сборки, тестирования или запуска инструментов командной строки.

5. Проверьте TypeScript-проекты дополнительными настройками

Если проект использует TypeScript, компилятор может дополнительно обнаруживать неиспользуемые объявления. Включите соответствующие параметры в tsconfig.json:

{
  "compilerOptions": {
    "noUnusedLocals": true,
    "noUnusedParameters": true
  }
}

После изменения конфигурации выполните проверку типов:

npx tsc --noEmit

Эти параметры подходят для контроля исходного кода во время разработки. В некоторых проектах их включение требует постепенного исправления существующих предупреждений.

6. Ищите мёртвый код, который инструменты не видят

Часть неиспользуемого кода нельзя надёжно определить только статическим анализом. Проверьте вручную следующие места:

• старые компоненты интерфейса после редизайна;
• утилиты, оставшиеся после замены библиотеки;
• обработчики событий, которые больше не подключаются;
• экспериментальные функции и временные флаги;
• старые конфигурации и неиспользуемые скрипты.

Для поиска кандидатов удобно использовать поиск по импортам и именам файлов. Например, если найден файл legacyParser.js, сначала проверьте все места его импорта:

grep -R "legacyParser" src

Команда зависит от операционной системы и оболочки. В Windows аналогичный поиск можно выполнить средствами PowerShell или редактора кода.

7. Удаляйте код безопасными итерациями

1. Создайте отдельный коммит перед очисткой.
2. Удаляйте небольшие группы связанных файлов.
3. Запускайте тесты после каждого значимого удаления.
4. Проверяйте production-сборку, если проект её использует.
5. Сравнивайте размер итогового бандла только после завершения серии изменений.

Минимальный цикл проверки может выглядеть так:

npx eslint .
npx tsc --noEmit
npm test
npm run build

Названия команд тестирования и сборки зависят от конкретного проекта и должны соответствовать скриптам в файле package.json.

Частые ошибки при поиске неиспользуемого кода

Итоговый чек-лист

• Включить проверку неиспользуемых переменных через ESLint.
• Проверить неиспользуемые файлы, экспорты и зависимости специализированным анализатором.
• Для TypeScript включить проверки компилятора при необходимости.
• Проверить динамические импорты, плагины и внешние точки интеграции.
• Удалять код небольшими изменениями с проверкой тестов и сборки.

Источники

• https://eslint.org/docs/latest/rules/no-unused-vars
• https://www.typescriptlang.org/tsconfig/#noUnusedLocals
• https://www.typescriptlang.org/tsconfig/#noUnusedParameters
• https://docs.npmjs.com/cli/