php - instalar - Symfony2: crear un paquete de proveedores propios: estrategia de proyecto y git

symfony issues

Question

Estamos considerando crear nuestro propio paquete common para mapeo de entidades y servicios para su uso dentro de algunas aplicaciones separadas. Un paquete debe ser fácil de modificar, ejecutar, incluir y probar. Conozco las mejores prácticas para la estructuración de lotes , pero no sé qué estrategia git utilizar cuando se trata de desarrollo.

¿Deberíamos crear common paquete common como un proyecto completo y comprometer todo el repositorio a nuestro servidor git, o es mejor iniciar el control de fuente solo para la raíz del paquete common e insertar solo sus contenidos? Veo este enfoque en paquetes disponibles en github , pero no conozco una manera fácil y cómoda de desarrollar paquetes de esa manera.

Answer 1

Crea un nuevo proyecto de 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 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

Agregue un archivo composer.json

src/Company/DemoBundle/composer.json :

{
"name" : "company/demobundle",
"description" : "A demo bundle",
"type" : "symfony-bundle",
"authors" : [{
"name" : "demo",
"email" : "[email protected]"
}],
"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 carpeta src/Company , luego instalarlo manualmente
• Puedes usar symlink

Conclusión

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

Answer 2

En Symfony4, el comando generate:bundle ya no está disponible. En cambio, puedes seguir este tutorial .

Primero crea un proyecto con:

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

Luego, cree un directorio my-project/lib/AcmeFooBundle/src . Aquí vivirá tu paquete. El espacio de nombre 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 nombre sería Acme/AcmeFooBundle/Service .

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

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

y ejecuta el composer dump-autoload .

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

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

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

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

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

Eso es todo. Siga las mejores prácticas y continúe con la codificación.

Answer 3

Un punto importante que debe saber es que puede comprometerse con su repositorio del / proveedor. De hecho, el compositor crea un segundo control remoto llamado "compositor" 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 -v desde cualquier paquete en 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 cual 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.