NEW
Font size
WorksheetsModule bundlers
Total questions: 10
Worksheet time: 5mins
Яку з цих проблем НЕ вирішував старий підхід із ручним додаванням <script> тегів у HTML?
Порядок завантаження скриптів мав критичне значення.
Кожен скрипт створював окремий HTTP-запит, сповільнюючи завантаження.
Змінні з різних файлів часто конфліктували у глобальному просторі імен.
Код автоматично транспілювався для підтримки старих браузерів.
Яку основну проблему вирішував патерн IIFE (Immediately Invoked Function Expression)?
Автоматичне керування залежностями між файлами.
Ізоляцію коду та запобігання забрудненню глобального простору імен.
"Ліниве" завантаження модулів за вимогою.
Транспіляцію синтаксису TypeScript у JavaScript.
З якого фундаментального кроку будь-який бандлер починає свою роботу?
Мініфікація всіх файлів у проєкті.
Запуск локального dev-сервера.
Побудова графу залежностей, починаючи з точки входу (entry point).
Розділення коду на асинхронні частини (чанки).
Чому оптимізація Tree Shaking (видалення "мертвого коду") найбільш ефективна саме з ES Modules (ESM)?
Тому що CommonJS є застарілим стандартом.
Тому що синтаксис import/export у ESM є статичним, і бандлер може проаналізувати його на етапі збірки.
Тому що ES Modules автоматично додають поліфіли.
Тому що CommonJS не дозволяє експортувати декілька функцій з одного файлу.
Який інструмент відомий своєю революційною ідеєю НЕ бандлити код у режимі розробки, а використовувати нативні ES-модулі браузера для миттєвого запуску?
Webpack
Rollup
Vite
Esbuild
Якщо ваша головна мета — створити NPM-пакет (бібліотеку) з мінімально можливим розміром бандлу та найчистішим кодом, який бандлер буде найкращим вибором?
Parcel
Rollup
Webpack
Vite
У чому головна причина феноменальної швидкості сучасних інструментів, таких як esbuild та Turbopack?
Вони написані на JavaScript, що робить їх сумісними з усім.
Вони використовують штучний інтелект для передбачення змін.
Вони написані на компільованих мовах (Go/Rust), що забезпечує значно вищу продуктивність.
Вони відмовилися від функції Code Splitting на користь швидкості.
Яку проблему може створити надмірне використання "burrel files" (index.js, що експортують усе з папки)?
Це може ускладнити роботу TypeScript.
Це може зламати або значно погіршити ефективність Tree Shaking.
Це обов'язково призведе до помилок під час виконання.
Це сповільнює роботу Hot Module Replacement (HMR).
Як бандлери вирішують проблему конфлікту імен змінних між різними модулями у фінальному bundle.js?
Вони автоматично перейменовують усі змінні на унікальні ID.
Вони обгортають код кожного модуля в окрему функцію, створюючи приватну область видимості.
Вони вимагають від розробника використовувати лише унікальні імена змінних.
Вони видають попередження про конфлікти, але не вирішують їх.
Уявіть, що ви написали такий код: const greet = (name) => Promise.resolve(Привіт, ${name});. Вам потрібно, щоб він запрацював у старому браузері, який не підтримує ані стрілкові функції, ані Promise.
Babel перетворить і стрілкову функцію, і Promise. Поліфіли не потрібні.
Поліфіл для Promise буде додано, а Babel транспілює стрілкову функцію в звичайну function.
Babel перетворить Promise, а поліфіл додасть підтримку стрілкових функцій.
Поліфіли будуть додані і для Promise, і для стрілкових функцій. Babel не потрібен.
