Комментарии 19
вот тоже хорошая стать habrahabr.ru/post/145946
НЛО прилетело и опубликовало эту надпись здесь
Теперь с помощью Composer все зависимости будут установлены в папку vendor в корне вашего проекта
Согласно документации, папку можно поменять — директивой «vendor-dir»
Странно что вы не упомянули «require-dev», т.к. часто есть библиотеки которые нет смысла хранить на production сервере.
Согласно документации, папку можно поменять — директивой «vendor-dir»
Что является плохой практикой, поэтому не стоит это упоминать.
А по какой причине это плохая практика?
Вы не задумывались о том, что бывают проекты совсем без фреймворков например, где структура папок определяется фантазией и чувством прекрасного разработчика?
Я бы тоже с удовольствием выслушал.
Какие-то аргументы в пользу «хорошая» и «плохая» можно услышать?
Я бы тоже с удовольствием выслушал.
Задумываюсь. Но в любом проекте есть точка входа, composer помимо установки пакетов создает автолоадер, который нужно подключить в этой точке и больше не задумываться об этом.
Если вы меняете название директории vendor, которая является стандартом для php, или node_modules для node — вы автоматически создаете сложности тем, кому этот проект нужно будет поддерживать. И совсем не важно, на каком фреймворке, или без него вы пишите.
Если рассуждать так, как вы, то фантазией разработчика, уставшего от надоедливых пользователей может быть переименование сущности User на Monkey, вы тоже это считаете вполне себе нормальным?
Вот пост на эту тему
Если вы меняете название директории vendor, которая является стандартом для php, или node_modules для node — вы автоматически создаете сложности тем, кому этот проект нужно будет поддерживать. И совсем не важно, на каком фреймворке, или без него вы пишите.
Если рассуждать так, как вы, то фантазией разработчика, уставшего от надоедливых пользователей может быть переименование сущности User на Monkey, вы тоже это считаете вполне себе нормальным?
Вот пост на эту тему
Если вы меняете название директории vendor, которая является стандартом для php
А можно ссылочку на стандарт PHP для именования папки с зависимостями?
Если вы меняете название директории vendor, которая является стандартом для php, или node_modules для node — вы автоматически создаете сложности тем, кому этот проект нужно будет поддерживать. И совсем не важно, на каком фреймворке, или без него вы пишите.
Если рассуждать так, как вы, то фантазией разработчика, уставшего от надоедливых пользователей может быть переименование сущности User на Monkey, вы тоже это считаете вполне себе нормальным?
Я не могу понять, как я создаю сложности тем, кто будет поддерживать проект? Если принимается решение об именовании папки vendor каким-либо другим именем, наверняка для этого есть причина?
— Существующий проект. Наверняка. Если есть причина, то, скорее всего, все те, кто поддерживает проект — вкурсе изменения
— Новый проект. Если я начинаю поддерживать какой-то проект, в котором изначально было принято решение о другом имени для папки с зависимостями, то какие трудности это создает для меня? :)
Composer Vendor Directory пост
«One True Vendor» — не сильный аргумент, а стремление автора к consistency. Там говорится о том, что папка vendor — «задумано по дизайну». И приводится «хорошая причина для такого дизайна»:
Composer targets the PHP community. It aims to grow the library space. Libraries should be small, focused, flexible and avoid side-effects. The user should be in control.
Если папка будет отлична от vendor — ничего не идет вразрез с «хорошим дизайном» (отсылка к тексту параграфа One True Vendor).
«Autoloading» — не нашел сильных аргументов. Зато есть:
A composer-managed application should have exactly one single include statement. A require vendor/autoload.php in the front controller
Почему это не может быть «require vendor-dir/autoload.php» неясно.
«Single directory» — тоже все весело. Особенно порадовало:
Third, version control. No need to litter your gitignore with random garbage
Т.е. папку vendor, создавая новый проект, совсем не надо добавлять ее в .gitignore :)
Isolation — единственное «заключение» в нем это:
Enough of that. That's why composer is a dependency manager and not a package manager. It manages deps per-project, it isolates them. It disallows sharing the same package directory between projects
Как это связано с именованием папки зависимостей? Неясно. Зато — «мамой клянус!» («trust me, it's totally worth it») присутствует :)
Итог
Человек, написавший пост, явно устал от управления зависимостями с PEAR, особенно работая с несколькими проектами, которые зависят от разных библиотект. И он (человек) стремится к согласованности в именовании папки, что поощримо (я сам ЗА consistency в проектах). Но аргументов нет, есть только — «ппц, да это не круто именовать папку отлично от vendor».
Я тоже предпочитаю «vendor», hell0w0rd, тем более, что пока не приходилось иметь дизайн приложения, который требовал бы изменения дефолтной конфигурации. Но я не исключаю возможности такой необходимости.
И если все зависимости хранятся в одной папке, а не разбросаны по проекту — то по-сути все равно, какая эта папка (если уж дефолтное название изменено, возможно, есть на то причина).
svscorp уже отлично ответил на Ваш комментарий и я с ним полностью согласен. От только одно забыл — если папка зависимостей не
«vendor» — то путь к ней всегда можно посмотреть в composer.json и ее имя или положение относительно корня проекта не иммет никакого значения.
«vendor» — то путь к ней всегда можно посмотреть в composer.json и ее имя или положение относительно корня проекта не иммет никакого значения.
НЛО прилетело и опубликовало эту надпись здесь
«require»: {
«php»: ">=5.4.0",
«monolog/monolog»: «1.9.*»
}
Дальше просто нужно в командной строке выполнить команду composer update, и все новые зависимости будут подгружены в папку vendor, и вы сможете их использовать
qwerty@qwerty ~/work/php/composer $ composer update
[Seld\JsonLint\ParsingException]
"./composer.json" does not contain valid JSON
Parse error on line 1:
«require»: { «php»: ">=5.
--------^
Expected one of: 'EOF', '}', ',', ']'
Не серьезно ведь, вроде как и для новичков пишете, а если не знаком с композером то и не разберется сам.
«php»: ">=5.4.0",
«monolog/monolog»: «1.9.*»
}
Дальше просто нужно в командной строке выполнить команду composer update, и все новые зависимости будут подгружены в папку vendor, и вы сможете их использовать
qwerty@qwerty ~/work/php/composer $ composer update
[Seld\JsonLint\ParsingException]
"./composer.json" does not contain valid JSON
Parse error on line 1:
«require»: { «php»: ">=5.
--------^
Expected one of: 'EOF', '}', ',', ']'
Не серьезно ведь, вроде как и для новичков пишете, а если не знаком с композером то и не разберется сам.
А не было сказано, что в данном коде указан валидный и полный json для файла composer.json. Описан только раздел require. Естественно, только эта часть не является валидным json.
Не суть важно что там было а что не было указано, если пишется для новичков (что собственно и было указано в начале статьи) то нужно учитывать что они как обезьянки повторяют все шаг в шаг, и логично было бы привести такой пример, который действительно работает, от двух скобочек руки не отпали бы наверно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Composer & Packagist 101