Яка різниця між CodeKit і Composer?

Оскільки я писав про CodeKit і Composer (справді, більше про останніх у останніх публікаціях), я час від часу отримую електронні листи із запитанням, який я справді віддаю перевагу використанню, коли справа доходить до роботи над проектами для інших.

І коротка відповідь полягає в тому, що вони не є взаємовиключними. У всякому разі, вони можуть доповнювати один одного. Вони не є замінниками один одного.

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

Крім того, інтерфейсна розробка відрізняється від бекенд-розробки, чи не так? Отже, знову ж таки, чому ми запитуємо:

Чи варто мені використовувати CodeKit чи Composer?

Ось тут і вступає в дію довша відповідь.

CodeKit і Composer

Для тих, хто дивиться на обидві ці утиліти і цікавиться різницею в кожній, це добре.

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

CodeKit

Коротше кажучи, мета CodeKit полягає в тому, щоб допомогти об’єднати багато нових інструментів, які ми часто бачимо (як -от Sass або LESS, такі фреймворки, як Foundation, і оптимізація зображень) в одну програму та завершити її, щоб було менше роботи, коли вона доходить до конфігурації.

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

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

Композитор

Composer, з іншого боку, призначений для керування залежностями, які працюють у поєднанні з вашою програмою. Це може бути щось на зразок PHP CodeSniffer. Або це може бути щось на зразок сторонньої бібліотеки, наприклад Monolog, яка допомагає вашому проекту відстежувати події, що відбуваються під час виконання.

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

Отже, якщо ви шукаєте щось на зразок CodeKit (чи NPM, чи Yarn) для серверної сторони, то Composer — це те, що вам потрібно використовувати. Він не має інтерфейсу, тому все виконується за допомогою файлів конфігурації (наприклад, NPM), але він також добре задокументований і досить простий у використанні, коли ви знайомі зі структурою файлів конфігурації.

І це різниця

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

Коли мова заходить про зовнішню розробку, існують інші інструменти, які люди обирають використовувати, наприклад NPM і Yarn. Я згадую їх тут лише тому, що вони також є менеджерами пакетів, подібно до Composer, але для інтерфейсу.

І, якщо що, вони ближчі до порівняння з Composer. Незважаючи на це, вони в основному зосереджуються на зовнішніх інструментах розробки. Можливо, варто зануритися в кожну з них у наступній публікації.