Обновление документации в июле 2017

Ребят, молодцы на счет composer, но пожалуйста дайте четкий стандарт размещения. "Кто как хочет так и размещает" - это бардак!
В документации про composer следует упомянуть обязательно про то как устанавливать с помощью composer bitrix модули.

Ну давайте еще специфицируем, с какой ноги утром вставать Composer устроен крайне примитивно и, мне кажется, сам разработчик способен принять решение как удобнее его встроить. Думаем про PSR-4 и согласованную поддержку автолоадинга Composer в модулях, да, тут еще не все понятно как сделать проще и удобнее. Со временем, надеюсь, опишем и best-practices.

скорее бы эти времена...
диаграммы классов еще бы...

Александр,
1. Далеко не каждый разработчик из статьи + небольшого гугления узнает что есть патч для Bitrix в https://github.com/composer/installers от notamedia, который даст удобную унифицированную возможность в компании централизованно управлять на проектах сущностями Bitrix: модуль, компонент, шаблон, и для разработчика это гораздо более удобный инструмент чем маркетплейс с поддержкой 1251, особенно для внутренних наработок компании которые нужно масштабировать на ряд проектов.

2. "сам разработчик способен принять решение как удобнее его встроить" - вот это и есть бардак. Bitrix благо для веб-студий и клиентам благодаря тому что консолидировал рынок, клиент может переносить проект из студии в студию, не наталкиваясь на доп. затраты на изучение платформы. Но последней мили по наведению порядка и унификации разработки на платформе Bitrix не делает, в итоге в стране тысячи студий, и у каждой свой внутренний стандарт. Причем не от хорошей жизни, а от того что нет рекомендаций как правильно унифицировано это делать в платформе.

Вот скачиваешь laravel - и у тебя сразу папочка для тестов, папочка для миграций, сразу указано как правильно должен располагаться docroot и vendor, где должны лежать конфиги npm, bower, gulpfile/webpack. И это правильно.

И ведь вам написать такую рекомендацию - разплюнуть, сесть 1 час подумать + 1 час на 1 статью в документацию. А сколько порядка для проектов оно принесет...

3. А еще умножьте это на реальный скил разработчиков малых студий которые только-только взялись изучать платформу или битриксоиды-самоучки. Что они сделают не подумав? Правильно, разместят vendor в корне, предварительно не закрыв ее что в принципе чревато потенциальными уязвимости в проекте.

п.1 спасибо за ссылочку, надеюсь инструмент окажет некоторым коллегам пользу.

п.2 в чем-то согласен и еще искренне верю, что появится у нас и CI с рекомендациями в коробке для крупных проектов. Недавно интерволга заопенсорсила инструмент миграции между установками - молодцы!

п.3 ну размещать библиотеки в htdocs это же клиника, думаю все таки разработчики с головой дружат