Кращий код WordPress: файл блокування Composer
Перш ніж закінчити нашу дискусію про Composer, у нас залишилося обговорити одну важливу річ: каталог постачальника (і за розширенням файл блокування Composer).
Зокрема, нам потрібно поговорити про те, чому нам не потрібно закріплювати каталог постачальника в репозиторії, а як наші учасники можуть бути впевнені, що вони мають останню версію програмного забезпечення, необхідного для роботи з нашою кодовою базою.
Так, використання інструментів якості коду для написання кращого коду WordPress є важливим, але також важливо розуміти, як правильно керувати залежностями та нашим репозиторієм. Отже, перш ніж дивитися на зазначені утиліти, давайте розглянемо файл блокування, роль, яку він відіграє, і чому нам не потрібно закріплювати каталог постачальника в нашому репозиторії.
Кращий код WordPress із файлом блокування Composer
Для тих, хто працює з WordPress – і, можливо, з іншими фреймворками та основами на основі PHP (я точно не знаю, оскільки зазвичай не працюю з ними) – покладаються на Composer, і це добре.
Це також може призвести до бажання закріпити весь контроль джерела каталогу постачальника, що не добре.
Як згадувалося в попередній публікації :
І я не рекомендую перевіряти каталог постачальників у вашому репозиторії. Пізніше це може стати величезним каталогом, і це може підірвати ціль Composer.
Отже, як ми можемо переконатися, що ми без потреби не закріплюємо файли (і таким чином роздуваємо розмір нашого сховища) до сховища, водночас переконуючись, що наші учасники використовують ту саму версію програмного забезпечення, що й ми?
Бажання закріпити каталог постачальників
Для тих із вас, хто запустив Composer і знайомий принаймні з переглядом каталогу постачальника, ви, ймовірно, звикли бачити кілька каталогів встановлених залежностей.
І вони корисні; інакше ви б їх не включили, чи не так?
Але ось що стосується каталогу постачальника : навіть якщо у вашому проекті встановлено лише кілька залежностей, сам розмір файлу може бути великим. І це може бути ще більше, якщо у вас багато залежностей.
Не дивлячись на це, здається, має сенс передати це системі керування джерелами, чи не так? Ми хочемо переконатися, що всі мають однакову версію програмного забезпечення, яке ми використовуємо, і ми хочемо переконатися, що їм не доведеться мати справу з Composer.
Але є інший спосіб. І це зберігає наше сховище невеликим, а також гарантує, що версії наших залежностей зберігаються в синхронізації з тими, хто клонує репозиторій, фіксує репозиторій або для будь-якої утиліти постійної інтеграції, яка використовує репозиторій.
Розуміння файлу блокування
Перш ніж говорити про каталог постачальників, я хочу торкнутися ще одного важливого аспекту Composer: файлу блокування. Тобто, якщо ви запустите команду встановлення або оновлення у вашому терміналі, ви побачите файл блокування, згенерований разом із каталогом постачальника .
Що це за файл?
У попередній публікації було показано приклад файлу конфігурації. Одна з речей, які цей файл також дозволяє нам робити, це визначати сторонні бібліотеки або залежності, які ми можемо використовувати в наших проектах.
Я говорив про це в інших публікаціях (і ми можемо розглянути це трохи пізніше в цій серії). Але тут вступає в дію файл блокування.
Коротше кажучи, файл блокування завжди містить інформацію про версію – точну версію – залежностей, які використовувалися з проектом під час останнього запуску інсталяції або оновлення.
Коли Composer завершує встановлення, він записує всі пакети та їх точні версії, які він завантажив, у файл composer.lock, блокуючи проект до цих конкретних версій.
Ви повинні зафіксувати файл composer.lock у своєму репозиторії проекту, щоб усі люди, які працюють над проектом, були заблоковані до тих самих версій залежностей (докладніше нижче).
Мета полягає в тому, щоб переконатися, що кожен запускає ту саму версію залежностей проекту – не старіші версії, не новіші версії – а ту саму версію.
Отже, коли ви запускаєте програму встановлення композитора, коли файл блокування включено до сховища, використовуватиметься версія програмного забезпечення, визначена у файлі блокування.
І це гарантує, що кожен працює з тією самою версією кожної залежності, і, таким чином, може запобігти необхідності передавання каталогу постачальника для керування джерелами.
Написання коду вищої якості
Тож куди нам далі йти?
Тепер, коли ми розуміємо, як використовувати Composer і як використовувати файл блокування, ми можемо почати говорити про фактичні залежності, які допомагають покращити якість нашого коду.
І коли ми говоримо про написання якіснішого коду, існують утиліти, створені саме для цього. Тож у кількох наступних публікаціях ми розглянемо деякі з них.