В чем разница между CodeKit и Composer?

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

И короткий ответ заключается в том, что они не исключают друг друга. Во всяком случае, они могут дополнять друг друга. Они не заменяют друг друга.

Чем меньше я перешел от проектов, ориентированных на интерфейс, тем меньше я использую CodeKit. И чем больше я продвигаюсь к разработке, ориентированной на бэкэнд, тем больше я использую Composer.

Кроме того, фронтенд-разработка отличается от бэкэнд-разработки, верно? Итак, опять же, почему мы спрашиваем:

Должен ли я использовать CodeKit или Composer?

Вот где более длинный ответ вступает в игру.

КодКит и Композитор

Для тех, кто смотрит на обе эти утилиты и интересуется различиями между ними, это хорошо.

Всякий раз, когда кто-то ищет способы улучшить свой процесс разработки с помощью инструментов, облегчающих разработку, я думаю, что это показывает уровень зрелости в разработке.

КодКит

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

Дело в том, что он включает в себя много вещей. Впрочем, это неплохо. Это действительно сводится к тому, чтобы выбрать то, что вы хотите, установить несколько флажков, а затем убедиться, что приложение знает о вашей кодовой базе.

Оттуда он позаботится, скажем, об автоматической компиляции вашего Sass всякий раз, когда вы сохраняете файл, который является частью вашего проекта.

Композитор

С другой стороны, Composer — это управление зависимостями, которые работают вместе с вашим приложением. Это может быть что-то вроде PHP CodeSniffer. Или это может быть что-то вроде сторонней библиотеки, такой как Monolog, которая помогает вашему проекту отслеживать события, происходящие во время выполнения.

Как бы то ни было, вы можете видеть, что пакеты, за управление которыми отвечает Composer, больше связаны с разработкой на стороне сервера, чем с разработкой интерфейса.

Поэтому, если вы ищете что-то вроде CodeKit (или NPM, или Yarn) для серверной части, то Composer — это то, что вам нужно. У него нет интерфейса, поэтому все делается через конфигурационные файлы (например, NPM), но он также хорошо документирован и достаточно прост в использовании, если вы знакомы со структурой конфигурационных файлов.

И в этом разница

Как упоминалось в начале поста, CodeKit и Composer не исключают друг друга. Во всяком случае, они могут работать в сочетании друг с другом, помогая построить проект как с внешней, так и с внутренней стороны.

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

И, во всяком случае, они ближе к сравнению с Composer. Тем не менее, они сосредоточены в первую очередь на инструментах разработки интерфейса. Возможно, стоит углубиться в каждый из них в следующем посте.