Compositor: utilizando un repository local

Soy un principiante Compositor y estoy tratando de hacer que un proyecto dependa de otro, mientras que ambos proyectos solo existen en mi máquina local.

El composer.json en mi proyecto de biblioteca (ProjectA) es:

{ "name" : "project/util", "type" : "library" } 

Inicialice git en la carpeta base de este proyecto.

Mi composer.json en el proyecto dependiendo del primero (ProjectB):

 { "repositories": [ { "name" : "util", "type" : "git", "url" : "/d/workspaces/util" } ], "require": { "project/util" : "*" }, } 

Cuando ejecuto la composer install del composer install desde ProjectB, aparece el siguiente error:

 [RuntimeException] Failed to clone , could not read packages from it fatal: repository '' does not exist 

Supongo que algo está mal con la url del repository, pero no estoy seguro de qué más escribir allí.

Creo que acaba de get la syntax incorrecta. El tipo debe ser simplemente VCS, y luego el compositor determina qué tipo de VCS es.

Entonces, en su proyecto B, la input para repositorys debería ser:

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

No necesita nombrar qué biblioteca está disponible en /d/workspaces/util . Composer escaneará el file composer.json en ese directory y sabrá qué nombre de proyecto está disponible allí, y usará el proyecto de ese directory con preference a una versión listda en packagist u otro repository.

Autoload package local utilizando compositor (sin ir a packagist cada vez que cambie).

Hay muchas maneras de hacerlo, estaré cubriendo 2 de ellos:

En todos los casos tenemos 2 partidos principales:
– el package local (el código que no queremos publicar en packagist para poder cargarlo automáticamente en nuestro proyecto).
– el proyecto principal (la base de código que necesita usar el código del package local, puede ser otro package o cualquier proyecto).


Methode 1: (espacio de nombre directo)

Abra el file principal composer.json proyecto y autocargue los espacios de nombres del package local utilizando cualquier método (PSR-4, PSR-0, …).

ejemplo:

si en el composer.json del package local tenemos:

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

luego en el compositor.json del proyecto principal deberíamos tener:

  "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" } }, 

Ventajas:
– no tocas el directory del proveedor (la ejecución de la actualización del compositor por error no anulará tus cambios locales)
– no necesita que su package esté en packagist para usarlo
– trabajas en un lugar (el package local) y los cambios se cargan automáticamente en el proyecto principal
Desventajas:
– No puede publicar el composer.json en producción (necesita editar antes de publicar para requerir el package real)

Methode 2: (repository local)

Descargue el package local de un repository local.

package local:
1. Inicialice git en el package (incluso si no desea usarlo, no necesita confirmar nada)
2. agrega el file composer.json. En el file, asegúrese de tener lo siguiente:

 "name": “vendor-name/package-name", "autoload": { … // use whichever method you prefer, but make sure it's being loaded correctly "minimum-stability": “dev" 
  1. composer dump-autoload

proyecto principal:
1. edite su composer.json para que contenga lo siguiente:

  "repositories": [ { "type": "vcs", "url": “/full/path/to/the/local/package/package-name" } ], "require": { "vendor-name/package-name": "dev-master" }, 
  1. Composer update vendor-name / package-name
  2. ahora mira el directory de tu proveedor, deberías ver el nombre del proveedor / nombre del package

NOTA: cada vez que realice un cambio en el package local (no en el proveedor) debe realizar la confirmación, luego puede actualizar el proyecto principal, obtendrá la copy más reciente del repository en el directory principal del proveedor del proyecto.

Ventaja:
– No toques el directory del proveedor (ejecutar la actualización del compositor por error no anulará los cambios locales) – no necesitas que tu package esté en packagist para usarlo
Desventaja:
– tiene que seguir cometiendo sus cambios (en el package local) y luego ejecutar la actualización del compositor en el proyecto principal
– No puede publicar el composer.json en producción (necesita editar antes de publicar para requerir el package real)

Además de la solución de Danack: cambiar el path de / d / a d: / funcionó para mí.

Me gusta esto:

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