Symfony2 - creación de un paquete de proveedor propio - proyecto y estrategia de git


79

Estamos considerando crear nuestro propio commonpaquete para mapeo de entidades y servicios para usar con algunas aplicaciones separadas. Un paquete debe ser fácil de modificar, ejecutar, incluir y probar. Conozco las mejores prácticas para estructurar paquetes , pero no sé qué gitestrategia utilizar cuando se trata de desarrollo.

¿Deberíamos crear el commonpaquete como un proyecto completo y enviar el repositorio completo a nuestro servidor git, o es mejor iniciar el control de código fuente solo para la raíz del commonpaquete y enviar solo su contenido? Veo este enfoque en paquetes disponibles en github, pero no conozco una forma fácil y cómoda de desarrollar paquetes de esa manera.

Respuestas:


177

Crea un nuevo proyecto Symfony vacío

php composer.phar create-project symfony/framework-standard-edition demo/ 2.4.1
cd demo

Genera un nuevo paquete

(por ejemplo src/Company/DemoBundle)

php app/console generate:bundle
cd src/Company/DemoBundle/

Inicie su repositorio de github en src/Company/DemoBundle

git init
touch README.md
git add .
git commit -m "initial commit"
git remote add origin https://github.com/YourAccount/DemoBundle.git
git push -u origin master

Agregar un archivo composer.json

src/Company/DemoBundle/composer.json:

{
    "name" : "company/demobundle",
    "description" : "A demo bundle",
    "type" : "symfony-bundle",
    "authors" : [{
        "name" : "demo",
        "email" : "demo@company.com"
    }],
    "keywords" : [
        "demo bundle"
    ],
    "license" : [
        "MIT"
    ],
    "require" : {
    },
    "autoload" : {
        "psr-0" : {
            "Company\\DemoBundle" : ""
        }
    },
    "target-dir" : "Company/DemoBundle",
    "repositories" : [{
    }],
    "extra" : {
    "branch-alias" : {
            "dev-master" : "some_version-dev"
        }
    }
}

Ahora tienes la estructura base de tu paquete

Úselo en otro proyecto

composer.json:

    [...]
    "require" : {
        [...]
        "company/demobundle" : "dev-master"
    },
    "repositories" : [{
        "type" : "vcs",
        "url" : "https://github.com/Company/DemoBundle.git"
    }],
    [...]

Hacer:

curl -sS https://getcomposer.org/installer | php
php composer.phar update company/demobundle

aplicación / AppKernel:

new Company\DemoBundle\CompanyDemoBundle(),

Trabajar en ello

  • Puede clonar su DemoBundle en la src/Companycarpeta y luego instalarlo manualmente
  • Puedes usar un enlace simbólico

Conclusión

Puede desarrollar y probar su paquete en su primer proyecto y usarlo con github y composer en su segundo proyecto.


Ese es un buen paso a paso, sin embargo, sugeriría alojar en sus propios repositorios y usar Satis para dar servicio a dependencias privadas: getcomposer.org/doc/articles/…
Boris Guéry

seguro, pero tal vez tenga un repositorio privado en github.
Vincent Barrault

¡Gran respuesta @VBee! Investigué un poco hace unos días sobre el mismo tema, pero estaba más interesado en usar repositorios privados de Git o repositorios locales (preferido).
Jovan Perovic

@VBee ¡Gran tutorial, gracias! El repositorio privado no es un problema: tenemos nuestro propio servidor git. El problema es que realmente no entiendo cómo desarrollar un módulo común en equipo usando su solución. ¿Cada desarrollador tiene que crear un nuevo sf2proyecto y cloneeste repositorio src/? ¿Qué pasa composer.lockcon el proyecto principal y usarlo para asegurar la misma versión de cada biblioteca en todo el equipo? Si conoce una forma buena y eficaz de hacerlo, agréguela a su respuesta. ¡Gracias! :)
ex3v

3
Solo un error tipográfico composer.phat debería ser composer.phar
Stéphan Champagne

16

Un punto importante que debe saber es que puede comprometerse con su repositorio desde / vendor. De hecho, composer crea un segundo control remoto llamado "composer" para cada paquete (o paquete) que hace referencia al repositorio del paquete, para que pueda trabajar en él en un contexto de trabajo. Entonces, la buena práctica es registrar su paquete en su composer.json para todos sus proyectos y comprometerse desde su /vendor/MyCompany/MyBundle, desde cualquier proyecto.

Como prueba, simplemente ejecute git remote -vdesde cualquier paquete de su proveedor.

La mala práctica sería considerar su paquete como un proyecto separado y tener enlaces simbólicos con él. La razón principal por la que esta es la mala práctica es que no podrá declarar dependencias con su paquete. Además, tendrá algunas dificultades con el despliegue de sus proyectos.


Estoy creando un paquete de proveedor propio. Quiero poner este paquete, por ejemplo, en GitHub y usarlo en otros proyectos. ¿Debo generar un nuevo paquete en /srco en el /vendordirectorio al inicio? Cuando incluya este paquete en otro proyecto en el que estará, /vendorpero ¿dónde debería generarlos al principio?
Salida 196

5
Cree un nuevo proyecto vacío en GitHub que almacenará su paquete. Incluya un composer.json en él. Incluso puede enviar un composer.json muy simple, con solo el nombre y la descripción de su paquete. De vuelta en su proyecto, agregue un requisito a su nuevo paquete y haga un composer update. Ahora debería ver su paquete vacío en la carpeta del proveedor y puede trabajar en él. Si desea que su paquete sea público, agréguelo a Packagist.
flouflou2000

4

En Symfony4, el generate:bundlecomando ya no está disponible. En su lugar, puede seguir este tutorial .

Primero crea un proyecto con:

composer create-project symfony/website-skeleton my-project

Luego, crea un my-project/lib/AcmeFooBundle/srcdirectorio. Aquí vivirá tu paquete. El espacio de nombres para este directorio será Acme\AcmeFooBundle, por lo que si crea una clase de servicio en lib/AcmeFooBundle/src/Service/Foo.php, su espacio de nombres sería Acme\AcmeFooBundle\Service.

Ahora necesitamos decirle al autocargador del compositor que busque nuevas clases en ese nuevo directorio, así que necesitamos editar la composer.json autoloadsección:

"autoload": {
    "psr-4": {
        "Acme\\AcmeFooBundle\\": "lib/AcmeFooBundle/src/",
    }
}, 

y corre composer dump-autoload.

Ahora solo necesita agregar su clase de paquete a config/bundles.php:

return [
    ...
    Acme\AcmeFooBundle\AcmeFooBundle::class => ['all' => true],
];

e inyección de dependencia para cargar la configuración desde su paquete.

Si desea verificar sus servicios antes de agregar la inyección de dependencia, puede conectarlos automáticamente en config/services.yml:

services:
    ...
    Acme\AcmeFooBundle\Services\Foo: ~

Eso es todo. Siga las mejores prácticas y continúe codificando.

PD: publiqué una publicación con algunos consejos para desarrollar paquetes reutilizables de Symfony .


Por cierto, también creé un proyecto para desarrollar paquetes reutilizables: github.com/msalsas/symfony-bundle-skeleton
Manolo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.