Англійське слово esbuild

Весь зміст Esbuild — це швидкість, тому розмови про нього, як правило, зосереджені на тому, що саме швидко і чому — словник тут дозволяє вам пояснити це точно, замість того, щоб просто сказати « це швидше, ніж Webpack » і залишити це там.

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

** Пакетування ** — об’ єднання декількох модулів JavaScript і їх залежностей у єдиний файл виводу (або невеликий набір файлів), основна операція esbuild виконується на порядки швидше, ніж більшість пакетів, заснованих на JavaScript. “Збирання всієї програми займає менше секунди з esbuild — еквівалентна конфігурація Webpack займає близько двадцяти.”

** Мінімізація ** — зменшення вихідного коду за допомогою вилучення пробілів, скорочення назв змінних і вилучення мертвого коду, що виконується як окремий, але часто поєднаний крок з з’ єднанням. “Мініфікація скоротила пакет з 800КБ до близько 300КБ — це версія, яку ми фактично відправляємо в виробництво.”

** Transform ** — режим esbuild для перетворення синтаксису окремого файла (наприклад, видалення типів TypeScript або перескладання JSX) без з’ єднання з іншими модулями, корисний, якщо обробку з’ єднання виконує окремий пакетний менеджер. “Ми використовуємо esbuild тільки для кроку перетворення — Rollup все ще робить фактичне з’єднання, але esbuild знищує TypeScript на порядки величини швидше, ніж компілятор TypeScript.”

** API додатків ** — механізм esbuild для підключення до процесу збирання (розв’ язання нетипових шляхів імпорту, перетворення незвичайних типів файлів) написаний на JavaScript, хоча більш обмежений, ніж екосистема завантажувача Webpack за дизайном. “Ми написали невеликий додаток для обробки нашого нетипового імпорту .graphql — API додатка esbuild зробив це двадцятирічним файлом замість цілого пакунка завантажувача.”

** Відображення джерела ** — створений файл, який відображає позиції у зменшеному виводі назад до початкового джерела, що дозволяє зневаджувачу показувати початкові назви файлів і номери рядків замість зменшених незначних фрагментів. “Якщо не ввімкнено картування джерел, цей стековий трасування буде марним — він буде вказувати на перший рядок зменшеного файла розміром 400 КБ замість фактичного рядка джерела.”

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

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

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

Пояснення щодо поліпшення швидкості збирання: “Перехід з Webpack на esbuild для локальних розробників скоротив наш час перебудови з близько восьми секунд до менше ніж 200 мілісекунд — з’єднання і перетворення написані на Go, що є більшою частиною того, чому це набагато швидше.”

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

Опис рішення інструменту збирання: “Ми залишили Rollup для остаточного з’єднання, оскільки його екосистема додатків більш зріла, але ми використовуємо esbuild для кроку перетворення на кожному файлі - це найшвидший спосіб видалити типи TypeScript, які ми знайшли.”

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

• Розрізняти ** з’ єднання ** від ** перетворення ** явно — esbuild підтримує обидва, а об’ єднання їх робить неясним, чи є крок збирання об’ єднанням файлів, чи лише обробкою одного.
• Завжди перевіряти, чи увімкнено і вивантажено ** карти джерел ** перед зневадженням зменшеної помилки виробництва — у іншому випадку ви зневаджуєте вихідний код, а не код, який було написано.
• Згадуйте обмеження plugin API чітко, коли це є причиною для збереження іншого bundler у конвеєрі — це законний компроміс, а не невдача у прийнятті швидшого інструменту.
• Виміряйте ** мінімізації ** економії з реальними числами, коли виправдовуєте це в обговоренні збирання — «менший набір» неоднозначний, «зменшити його з 800КБ до 300КБ» є фактом, готовим до прийняття рішення.

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

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

На практиці: Навігація та співпраця

Будьмо чесними - коли ви створюєте програмне забезпечення, особливо в командному середовищі, комунікація є всім. Це не просто написання коду; це пояснення вашого коду іншим, отримання зворотнього зв’язку про цей код, і, врешті-решт, спільна робота над спільною метою. І велика частина цього спілкування - це використання правильного словника, коли обговорюються технічні процеси, такі як будівництво з esbuild.

Часто люди, для яких англійська не є рідною, стикаються з труднощами у вираженні складних ідей, пов’ язаних з такими термінами, як «з’ єднання» або «мінімізація». Перекласти їх безпосередньо з вашої рідної мови легко, але нюанси і точні формулювання, що використовуються в професійній розробці програмного забезпечення, можуть бути складними. Наприклад, просто сказати «Ми з’єднали наш код» не повністю передає * чому * за ним. Ефективнішим підходом було б: « Ми використовували esbuild для з’ єднання, що значно зменшило кількість HTTP- запитів, необхідних для завантаження нашої програми, і поліпшило початковий час завантаження сторінки ». Зауважте, як це пояснення пов’ язує технічну дію (з’ єднання) з реальною перевагою — швидкодією!

Розглянемо такий сценарій: ви надіслали запит на звантаження, у якому містяться зміни до вашої бібліотеки компонентів. Під час перегляду коду старший розробник залишає коментар до одного з ваших файлів: « Цей файл можна було б ще більше зменшити; розгляньте можливість вилучення не використовуваних експортів ». Ключовим у цьому випадку є не лише розуміння * того, що * вони кажуть (зменшити розмір файла), але і * того, як * вони просять вас зробити це. Сказати «Гаразд, я зменшу це ще більше» неоднозначно. Краще відповідь буде: “Я ціную відгук про мініфікацію. Чи можете ви розібратися, які конкретні види експорту, на ваш погляд, можуть отримати користь від подальшого зменшення? Знання міркувань, які стоять за цією пропозицією, допоможе мені ефективно оптимізувати процес». Це демонструє не лише розуміння, але також бажання вчитися і співпрацювати. Це стосується оформлення ваших дій у більшому контексті оптимізації продуктивності, загальної мети в командах розробників.

Крім того, при написанні описів PR, чіткість є найважливішою. Замість загального « Виправлено помилку », спробуйте щось на зразок: « Впроваджено виправлення для [опис помилки] за допомогою esbuild, щоб зменшити розмір пакунка і поліпшити швидкість збирання. Ця зміна зменшує кінцевий файл JavaScript приблизно на 30% за допомогою стандартних методів мінімізації. » Це надає контекст і підсвічує інструменти, які використовуються, демонструючи активне спілкування.

esbuild src/index.js --bundle --outfile=dist/index.js --minify

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