Композитор - использование локального репозитория

Ответ 1

Автозагрузка локального пакета с использованием composer (без перехода на packagist при каждом изменении).

Есть много способов сделать это, я расскажу о двух из них:

Во всех случаях у нас есть 2 основные партии:
- локальный пакет (код, который мы не хотим публиковать на packagist, чтобы иметь возможность автоматически загружать его в наш проект composer).
- основной проект (кодовая база, которая должна использовать локальный код пакета, может быть другим пакетом и/или любым проектом).

Метод 1: (прямое пространство имен)

Откройте основной файл проекта composer.json и автоматически загрузите локальные пространства имен пакетов, используя любой метод (PSR-4, PSR-0,...).

пример:

если в composer.json локального пакета мы имеем:

  "autoload": {
    "psr-4": {
      "Local\\Pack\\": "library"
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Local\\Pack\\Tests\\": "tests"
    }
  },

тогда в composer.json основного проекта мы должны иметь:

  "autoload": {
    "psr-4": {
      "Mahmoudz\\Project\\": "src",
      "Local\\Pack\\": "../path/to/local/pack/library"                   << referencing the other local package
    }
  },
  "autoload-dev": {
    "psr-4": {
      "Mahmoudz\\Project\\Tests\\": "tests"
    }
  },

Преимущества:
- вы не трогаете каталог вендора (запуск обновления композитора по ошибке не отменит ваши локальные изменения)
- вам не нужно, чтобы ваша посылка была на упаковке, чтобы использовать ее
- вы работаете в одном месте (локальный пакет) и изменения автоматически загружаются в основной проект
Недостатки:
- вы не можете публиковать composer.json на производстве (перед публикацией необходимо отредактировать, чтобы запросить реальный пакет)

Способ 2: (локальный репозиторий)

Загрузите локальный пакет из локального хранилища.

локальный пакет:
1. инициализировать git в пакете (даже если вы не хотите его использовать - не нужно ничего фиксировать)
2. добавить файл composer.json. В этом файле убедитесь, что у вас есть следующее:

"name": "vendor-name/package-name",  

"autoload": { …   // use whichever method you prefer, but make sure its being loaded correctly

"minimum-stability": "dev"  

3. composer dump-autoload

основной проект:
1. отредактируйте ваш composer.json, чтобы он содержал следующее:

  "repositories": [
    {
      "type": "vcs",
      "url": "/full/path/to/the/local/package/package-name"
    }
  ],
  "require": {
    "vendor-name/package-name": "dev-master"
  },

2. композитор обновляет имя поставщика/имя package-
3. Теперь проверьте ваш каталог поставщиков, вы должны увидеть имя поставщика /package- имя

ПРИМЕЧАНИЕ: всякий раз, когда вы вносите изменения в локальный пакет (не поставщика), вам нужно выполнить git commit, тогда вы можете обновить композитор основного проекта, он получит последнюю копию репозитория в основной каталог поставщика проекта.

Преимущество:
- вы не трогаете каталог вендора (запуск обновления композитора по ошибке не отменит ваши локальные изменения) - вам не нужно, чтобы ваш пакет был на packagist, чтобы использовать его
Недостаток:
- вы должны продолжать фиксировать свои изменения (в локальном пакете), а затем запускать обновление композитора в основном проекте
- вы не можете публиковать composer.json на производстве (перед публикацией необходимо отредактировать, чтобы запросить реальный пакет)

Ответ 2

Я думаю, что вы только что получили синтаксис неправильно. Тип должен быть просто VCS, а затем композитор определяет тип VCS.

Итак, в вашем проекте B запись для репозиториев должна быть:

"repositories": [
    {
        "type": "vcs",
        "url" : "/d/workspaces/util"
    }
],

Вам не нужно указывать, какая библиотека доступна в /d/workspaces/util. Composer будет сканировать файл composer.json в этом каталоге и знать, какое имя проекта доступно там, и использовать проект из этого каталога, предпочитая версию, указанную в packagist или другом репозитории.

Ответ 3

В дополнение к решению Danack: изменение пути от/d/до d:/работал у меня.

Вот так:

"repositories": [
    {
        "type": "vcs",
        "url" : "d:/workspaces/util"
    }
],

Ответ 4

Я нашел этот учебник действительно полезным: https://johannespichler.com/developing-composer-packages-locally/ когда я столкнулся с проблемами с локальным производством пакетов

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

"options": {
        "symlink": true
      }