Англійська для Webpack

Повільна збірка, роздутий пакет або пошкоджений ланцюг завантажувача - це три абсолютно різні проблеми, і команда, яка може тільки сказати “збірка пошкоджена”, врешті-решт зневаджує сліпо - словник в цьому посібнику дозволяє вам назвати саме ту частину конвеєра Webpack, яка не працює.

Ключовий словник

** Вхідна точка ** — файл (або файли), з якого Webpack починає побудову свого графіка залежностей, зазвичай це кореневий файл програми, на зразок index.js, з якого буде виявлено і з’ єднано всі імпортовані модулі.

• “Ми додали другу точку входу для панелі адміністратора, тому вона буде збудована як окремий пакет замість того, щоб бути доставленою з кодом головної програми.” *

** Пакет ** — кінцевий файл (або файли) виводу, який Webpack створює після розв’ язання, перетворення і об’ єднання всіх модулів, доступних з точки входу. “Розмір пакунка збільшився до 2МБ після додавання залежності — нам потрібно перевірити, чи правильно він виконує дерево-штовхування перед відправкою.”

Chunk — частина коду Webpack розділяється від головного пакету, або автоматично (через розділення коду) або явно (через динамічний import() ), тому його можна завантажити окремо і часто ліниво.

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

** Завантажувач ** — перетворення, яке Webpack застосовує до файла перед його з’ єднанням, наприклад, перетворення Sass на CSS або TypeScript на JavaScript, налаштовано для кожного типу файла за допомогою правил у налаштуваннях. “Збирання зазнає невдачі, оскільки не налаштовано завантажувача для файлів .svg — Webpack не знає, як перетворити цей імпорт у щось, що можна з’ єднати.”

** Tree shaking ** — процес вилучення невикористовуваних експортів з кінцевого пакунка на основі статичного аналізу команд імпорту/ експорту, зменшення розміру пакунка за допомогою вилучення мертвого коду. “Дерево не працює тут, тому що бібліотека постачається як CommonJS, а не ES модулі — Webpack не може статично визначити, що не використовується, тому все це з’єднується.”

Звичайні фрази

• Чи є це проблемою завантажувача, або ж точка входу неправильно налаштована?»
• Чи можемо ми розділити це на його власну частину, щоб зберегти початковий збірку меншою?»
• «Чи справді дерево тріскає тут, чи мертвий код все ще з’єднується?»
• «Яка точка входу належить до цього файлу?»
• Чи є регресія розміру ланцюжка від нової залежності, або від чогось, що не тріскає дерево?»

Приклади висловлювань

Діагностика регресії розміру згортка: “Регрессия размера пакета является новой зависимостью, которая не является дерево-трясканием — она поставляется как CommonJS, так что Webpack должна включать всю библиотеку, а не только две функции, которые мы фактически используем.”

Пояснення рішення про розділення коду: “Ми пересунули сторінку налаштувань у її власний блок за допомогою динамічного імпорту, оскільки більшість користувачів ніколи не відвідують її — це скоротило приблизно на 40КБ початковий набір, який всі завантажують при завантаженні.”

Зневадження пошкодженої збірки: “Збирання не вдалося для нового типу файлів, оскільки для нього ще не налаштовано завантажувача — нам потрібно додати його до налаштувань Webpack, перш ніж цей імпорт буде розв’ язаний.”

Професійні поради

• При обговоренні розділення коду скажіть chunk, а не « separate file » — це означає, що ви розумієте реальну модель виводу Webpack, а не просто те, що файли були розділені якимсь чином.
• Посилання ** дерево тремтіння ** особливо коли збірка є несподівано великим від залежності — це вказує колегам прямо на те, чи бібліотека є ES- модуль- дружелюбний, а не нечітка “збірка є великим” скарги.
• Надати назву відсутньому ** завантажувачу ** безпосередньо, коли збірка зазнає невдачі з невідомим типом файла — це зазвичай найшвидший спосіб виправлення, і надання назви збереже колегу від повторного діагностування з нуля.
• Розрізняйте ** вхідна точка ** від ** набір ** під час пояснення збирання з декількох програм — об’ єднання цих двох елементів ускладнить для нової людини знання того, що відповідає якому параметру.

Практичні вправи

1. Напишіть речення, у якому пояснюється різниця між шматком і збіркою.
2. Пояснити, чому тріскання дерева може зазнавати невдачі для певної залежності.
3. Опишете сценарій, за якого ви додасте нову точку входу до налаштувань Webpack.

Навигація зворотного зв’язку — практичний підхід до технічної англійської

Ядро розуміння термінології Webpack полягає не лише в тому, щоб знати * що * це, але і як ефективно обговорювати їх з вашою командою. Часто, найскладнішим аспектом є не сам технічний аспект, а його чітке формулювання таким чином, щоб сприяє співпраці і уникнення непорозумінь. Розглянемо деякі реалістичні сценарії, де точна англійська мова стає вирішальною - особливо при отриманні або наданні зворотнього зв’язку про зміни коду.

Поширена ситуація під час перегляду коду. Сара може написати в Slack: «Я бачу деякі проблеми з налаштуванням webpack в цьому PR. Зокрема, babel-loader не обробляє функції ES6 правильно для цих компонентів, і це генерує непотрібно великі пакунки.” Ключ тут не * просто * ідентифікація проблеми; це чітке повідомлення про цю проблему Девіду, який відповідає за її вирішення. Використання точної термінології - “необов’язково великі пакунки”, “babel-loader”, “ES6 функції” - негайно встановлює спільне розуміння і направляє його увагу на конкретну область занепокоєння. Аналогічно, під час написання опису запитів на звантаження, уникайте нечітких тверджень на зразок « виправлено деякі проблеми зі збиранням ». Замість цього, докладно описуйте * що * було виправлено і * чому * це важливо: « Впроваджено нову стратегію розбиття веб- пакунків на частини для поліпшення часу початкового завантаження для мобільних користувачів. Це зменшує розмір головного пакету приблизно на 15 %»

Інший сценарій передбачає обговорення оптимізаційних стратегій з вашим лідером команди, Марком. Ви можете сказати: « Я думаю про використання розбиття коду, щоб розбити наші пакети JavaScript на менші частини — можливо, одну частину для основної функціональності, а іншу для інтерактивних компонентів. » Марку потрібно розуміти не лише поняття « розбиття коду », але також і те, як це сприяє кращому загальному процесу збирання. Ясне пояснення показує, що ви розумієте можливості Webpack, і надає змогу оцінити його придатність для проекту. Крім того, при описі складних перетворень, використання технічного словника, такого як «tree-shaking» або «мертвий код усунення» додає довіри і показує, що ви знайомі з передовими методами оптимізації.

Нарешті, розглянемо сценарій, у якому ви документуєте налаштування вашого webpack: « Ми використовуємо динамічний підхід імпорту для завантаження компонентів за потреби, зменшуючи початкову вагу сторінки ». Ця коротка фраза використовує встановлену термінологію для ефективного обміну інформацією у технічній документації.

Ось приклад використання webpack-cli для аналізу розміру згортка:

webpack --profile --json > stats.json

Ця команда створює файл stats.json, у якому міститься докладна інформація про процес збирання, зокрема, розміри збірки і часи. Аналіз цього виводу (і повідомлення його результатів) вимагає чіткої англійської мови, щоб ефективно пояснити результати іншим членам команди. Наприклад, «‘stats.json’ показує, що наш виробничий пакунок значно більший, ніж очікувалося, через невикористані імпорти CSS — нам потрібно дослідити це далі»