Повільний процес збірки та великий розмір теки node_modules - це проблеми, з якими стикаються багато розробників, але, здається, не помічають їх. Чому це відбувається? Через складну мережу залежностей npm. Кожного разу, коли ви запускаєте npm install, на додаток до пакунків, які вам явно потрібні, ваш проект також отримує всі їхні залежності, що значно збільшує розмір вашої кодової бази. Це може заважати вашому повсякденному робочому процесу і робити його менш ефективним, а також створювати потенційні ризики для безпеки.

У цій статті ми розглянемо ефективні стратегії для перегляду та покращення ваших npm-пакетів. Коли ви закінчите читати цю статтю, ви отримаєте краще розуміння того, як підтримувати ефективність і безпеку вашого проекту.

З точки зору проекту, "залежності" означають всі ті сторонні бібліотеки та інші інструменти, які потрібні вашому проекту для правильної роботи у виробничому або тестовому режимі. Розміщення бібліотек у правильному місці допомагає покращити вашу виробничу збірку. Щоб зрозуміти це краще, давайте розглянемо залежності та devDependencies.

Залежності - це зовнішні бібліотеки або пакети, необхідні вашому проекту для успішної роботи у виробничому середовищі. Коли ви встановлюєте пакунок або бібліотеку як залежність, ви заявляєте, що ваш проект потребує цього пакунка для належної роботи - як під час розробки, так і після того, як його буде розгорнуто для використання іншими.

Наприклад, коли ви створюєте проект з React, вам потрібно включити React і ReactDOM як основні залежності, тому що ці дві бібліотеки необхідні для рендерингу ваших React-компонентів у браузері. Все, що ви вкажете в "залежностях", буде включено до збірки для виробництва. Це впливає на багато речей, зокрема на продуктивність та безпеку додатку.

Dev-залежності пов'язані з тестуванням, аналітикою коду, лінтингом та локальною розробкою, які не використовуються у виробничому середовищі - на відміну від звичайних залежностей, які використовуються для запуску вашого додатку у виробничому середовищі. Зазвичай, компіляція вихідного коду, запуск тестів і лінтування для підтримки якості коду - це дії, які відбуваються на етапі розробки.

Наприклад, у React-додатку Babel часто використовується для перетворення JSX у форму JavaScript, зрозумілу браузерам; Jest або Storybook часто використовуються для створення модульних тестів для вашого коду. Такі інструменти мають вирішальне значення для процесу розробки, але після цього вони не мають особливого сенсу і можуть розглядатися як накладні витрати.

Ізоляція devDependencies допомагає зменшити навантаження на виробниче середовище. Коли ви використовуєте цю команду для встановлення пакунків для виробництва, npm виключає всі пакунки під devDependencies. Це призводить до зменшення розміру файлу програми і може призвести до швидшого розгортання і меншого використання пропускної здатності, що є критично важливим у виробничому середовищі.
Час збірки можна скоротити за допомогою простої техніки: оптимізації сторонніх бібліотек і використання лише необхідних частин.

Використовуйте невеликі модулі Node замість великих, де це можливо. Наприклад, в одному з моїх нещодавніх проектів я використовував date-fns для форматування дат у певному стилі. Ця бібліотека має понад 200 функцій для дат; це близько 5 000 файлів і 22 МБ загального розміру. Я не став імпортувати всю бібліотеку. Я імпортував лише один файл, необхідний для форматування дат, і це значно зменшило непотрібне роздування.

Подібним чином, lodash є популярною утилітою, яка виконує чудову роботу, надаючи багато функцій. Для одного проекту я взяв функцію _compact з lodash. Замість того, щоб імпортувати всю бібліотеку, я вирішив імпортувати лише цю функцію за допомогою рядка: "import compact from 'lodash/compact'. Таким чином, я зміг оптимізувати збірку і зберегти низький рівень залежностей.

Зі збільшенням масштабу проекту слід уважно стежити за сторонніми залежностями та їхнім впливом на збірку. Там, де це можливо, слід використовувати власні функції JavaScript замість зовнішніх бібліотек, щоб зменшити накладні витрати і сприяти більш впорядкованій кодовій базі.

Tree shaking - це відповідний термін для методу, який нагадує струшування дерева, щоб позбутися відмерлого листя. Він виявляє і видаляє невикористаний код, використовуючи статичну структуру синтаксису модулів ES2015.

Увімкнути струшування дерева за допомогою Webpack так само просто, як переключитися у "виробничий" режим. Однак, ви повинні протестувати все в середовищі розробки, перш ніж переходити до виробничого середовища. Для цього змініть режим на "розробка" і увімкніть його в конфігурації Webpack. Коли ви запустите збірку, Webpack створить файли з коментарями про невикористаний код (наприклад, "/* невикористаний квадрат експорту гармонії */").

Після перегляду невикористаного експорту поверніть режим на "production" у конфігурації Webpack. Це допоможе запустити процес маркування і видалити невикористаний код з виробничого пакета. Розбиваючи код на модулі з чіткими лініями експорту та імпорту, такі пакувальники, як Webpack, можуть легко знайти граф залежностей і пропустити непотрібний експорт, що робить збірку простішою і швидшою.

Невикористані залежності подібні до невикористаного коду; вони пропонують просту можливість зменшити розмір npm-збірки у великих проектах. Протягом життєвого циклу проекту багато бібліотек можуть застаріти або навіть створити проблеми з безпекою. Ці залежності часто залишаються непоміченими до тих пір, поки їх не викличе інструмент безпеки або поки збірка не почне давати збої. Існує приказка, яка описує подібні ситуації: якщо це не зламано, не виправляйте це.

Depcheck є чудовим інструментом для перегляду посилань у проекті Node та пошуку непотрібних. Після встановлення npm у вашій системі, його можна запустити просто за допомогою npx, програми для запуску пакунків, яка постачається разом з npm.

Іншим популярним лінтером є ESLint, який має вбудовані плагіни і правила, що допомагають знайти невикористані імпортовані дані. Він також покаже будь-які невикористані змінні у вашій кодовій базі. Ви можете додати ESLint до свого CI/CD конвеєра, щоб тестування виконувалося для кожного нового комміту. Це допомагає зменшити щоденні зусилля по управлінню невикористаними залежностями і сприяє підтримці чистої та ефективної структури проекту.

Основними способами зменшення розміру вашої збірки є мінімізація та стиснення, обидва з яких добре підтримуються Webpack. Разом ці методи можуть зменшити текстові ресурси на 70%. Мінімізація полягає у видаленні непотрібних символів з файлів коду, зберігаючи функціональність без змін. У попередньому режимі роботи Webpack для мінімізації JavaScript використовується плагін TerserPlugin.

Для досягнення подібних результатів у CSS можна використовувати плагіни. У поєднанні з ретельним кодуванням ці методи можуть значно зменшити розмір пакунків. У цій статті я включив окремий розділ, який підкреслює різні практики кодування, які допоможуть ще більше зменшити розмір вашої збірки під час мінімізації.

Усвідомлення впливу розміру встановлених модулів має важливе значення для підтримки ефективності вашого проекту. Інструмент CLI cost-of-modules пропонує простий спосіб оцінити розмір бібліотек, визначених у вашому проекті. Встановивши і запустивши цей інструмент, ви зможете точно визначити суттєві залежності, які можуть надмірно роздувати ваш проект.

Утиліта створить звіт, у якому буде вказано розмір кожного модуля, що дозволить виявити надмірно великі пакунки. Це дозволить вам приймати обґрунтовані рішення щодо заміни важких залежностей на легші або рефакторингу частин вашого коду.
Описані нижче практики кодування можуть суттєво вплинути на розмір вашого пакунка npm-збірки. Впровадивши ці практики у свій звичайний робочий процес, ви допоможете створити впорядковану та ефективну кодову базу.

Це стандартний метод, який слід використовувати для будь-якої мови програмування. Коли ви бачите функціонал, який повторюється багато разів, корисно виділити його в окрему функцію для багаторазового використання. Це не тільки зменшує загальний обсяг коду, але й покращує його читабельність та зручність супроводу.

Об'єкти можуть представляти деякі цікаві аспекти. Щоб зменшити надмірність і дозволити мініфікаторам оптимізувати код більш ефективно, варто деструктурувати об'єкт і присвоювати його змінній, коли до одного і того ж поля об'єкта звертаються повторно.

Функції-стрілки дозволяють використовувати більш компактний синтаксис, що може призвести до зменшення загального розміру коду при мінімізації. Коли декілька стрілочних функцій оголошуються послідовно з використанням const або let, всі, крім першого оголошення, мають скорочену форму. Стрілочні функції можуть повертати значення без використання ключового слова return.

Хоча мініфікатор може вставляти код в лінію, зменшення кількості змінних збільшує більшість зусиль з оптимізації.

Правильне керування залежностями npm має велике значення для керованості, безпеки та продуктивності ваших проектів. Найкращі практики, описані вище, піднімуть ваші процеси збірки на новий рівень. Використання таких інструментів, як і , а також ретельне кодування, зробить конкретний внесок у зменшення роздуття та покращення якості коду.

Методи, представлені в цьому посібнику, зменшують непотрібні залежності, покращують властивості об'єктів і використовують сучасні можливості JavaScript. Все це сприяє скороченню часу збірки та підвищенню ефективності кодової бази в цілому. Впровадження цих методів у ваш робочий процес дозволить вам зробити більш ефективний внесок у ваш проект, створивши при цьому масштабовану базу для майбутніх удосконалень. Регулярна і цілеспрямована оптимізація - це те, що в кінцевому підсумку призводить до швидшої збірки npm.