composer vs npm: многомодульная разработка

[VolCh]

А не исследовали как yarn себя ведёт на таких задачах? Обычно он более дружелюбен к разработчикам чем npm.

[flancer]

Нет, насколько я понял, после того, как npm ускорился после выхода yarn'а, интерес к yarn'у значимо упал. А меня интересовал наиболее типовой подход для сборки nodejs-приложения.

[hanovruslan]

Не буду оспаривать фичу одновременного коммита в несколько репозиториев, которая имхо довольно рисковая даже если есть хорошие тесты, но вообще-то у composer есть рекомендуемая схема для вложенных пакетов

Вместо

  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/flancer64/habr-cvsn-mod-base"
    }
  ]

Использовать

  "repositories": [
    {
      "type": "path",
      "url": "/local/path/to/flancer64/habr-cvsn-mod-base"
    },

Разница в том, что при любых настройках второй вариант будет давать свежее состояние вложенного проекта, а первый вариант может сбрасывать состояние при запуске команды composer update

Кроме того для git-хабов (github, gitlab, bitbucket и т.п.) есть другая рекомендуемая схема подключения кастомных репозиториев

      "type": "git",
      "url": "github.com:flancer64/habr-cvsn-mod-base.git"

в этом случае работа идет через ssh и настройки подключения определяются на уровне пользователя а не конкретного проекта. Например, на винде при подлючении пакета через https будет проверяться отдельная схема авторизации в git-хабе

ну и совсем мелочь, для composer есть парочка интересных плагинов, которые, кажется, не очень хорошо работают… однако предназначены для чего-то подобного, если под многомодульностью понимать аналог многомодульности из gradle а не, что в случае композера называется зависимость

1. wikimedia/composer-merge-plugin
2. beberlei/composer-monorepo-plugin