Estamos considerando la posibilidad de crear nuestro propio common paquete para la entidad de asignación y servicios para su uso dentro de pocas aplicaciones separadas. Un paquete debe ser fácil de modificar, ejecutar, incluir y prueba. Yo sé acerca de Las mejores Prácticas para la Estructuración de Paquetes, pero no sé qué git estrategia a utilizar cuando se trata de desarrollo.

Debemos crear common paquete como todo el proyecto y se comprometen todo el repositorio a nuestro servidor git, o es mejor empezar de control de código fuente sólo para la raíz de common paquete y enviar sólo su contenido? Veo este enfoque en paquetes disponibles en github, pero no sé fácil y cómoda para desarrollar paquetes de esa manera.

InformationsquelleAutor ex3v | 2014-02-03

3 Comentarios

  1. 175

    Crear un nuevo proyecto symfony vacío

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

    Generar un nuevo paquete

    (por ejemplo src/Company/DemoBundle)

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

    Init 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 compositor.archivo 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 usted tiene la estructura de la base de su paquete de

    Usarlo en otro proyecto

    compositor.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

    app/AppKernel:

    new Company\DemoBundle\CompanyDemoBundle(),

    Trabajar en él

    • Se puede clonar su DemoBundle en el src/Company carpeta, a continuación, instalar manualmente es
    • Puede utilizar un enlace simbólico

    Conclusión

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

    • Eso es un buen paso-por-paso, sin embargo, yo sugeriría que se aloja en sus propios repositorios, así como el uso de Satis para servicio privado dependencias: getcomposer.org/doc/articles/…
    • seguro, pero tal vez tiene un privado repositorio en github.
    • Gran respuesta @VBee! Hice algunas investigaciones hace unos días sobre el mismo tema, pero yo estaba más interesado en el uso de Git privado repos o local repos (de preferencia).
    • Gran tutorial, gracias! Privado repo no es un problema – tenemos nuestro propio servidor git. El problema es que yo realmente no se cómo desarrollar el módulo común en equipo a través de su solución. Cada desarrollador tiene que crear de nuevo sf2 proyecto y clone esta repo en src/ ? ¿Qué acerca de composer.lock para el proyecto principal y en su uso para asegurar la misma versión de cada biblioteca en equipo? Si conoces una buena y eficaz manera de hacerlo, por favor, añadir a su respuesta. Gracias! 🙂
    • editado. mi preferido de elección es de los enlaces simbólicos opción.
    • Sólo un error tipográfico compositor.phat debe ser compositor.phar
    • Para cualquiera que esté investigando este tema, usted puede tener una mirada en el repetitivo LilaConceptsBestPracticeBundle (github.com/LilaConcepts/LilaConceptsBestPracticeBundle). Le dará un buen punto de partida.
    • Cuenta que el parámetro "target-dir" : "Company/DemoBundle" utiliza la barra diagonal / al especificar destino de directorios, y "psr-0" :"Company\\DemoBundle" : ""} utiliza escapado ` \\ ` de barra diagonal inversa.
    • ¿qué hacer paquetes como Sylius hace? tiene muchos paquetes [SÓLO LECTURA] y «reemplazar» en el compositor.json, pero, ¿cómo funciona esto… no entiendo aún
    • Ahora usted puede utilizar path repositorio tipo, compositor va a crear enlaces simbólicos por sí mismo getcomposer.org/doc/05-repositories.md#path
    • Cómo agregar un proveedor dentro del Paquete? Quiero que mi paquete que se pegue el código para una biblioteca personalizada, de ahí que me quieres obligar a un proveedor de la biblioteca a por él, pero no estoy seguro de donde lo requieran. Creo que debería estar en el interior del Paquete del compositor.json.
    • Esto debe ser parte de la symfony documentación. Buen trabajo, thx
    • Usted puede crear compositor.archivo json con el compositor comando init ( getcomposer.org/doc/03-cli.md#init )
    • Usted puede utilizar el enlace simbólico como git no acepta los archivos más allá de enlaces simbólicos

  2. 16

    Un punto importante a saber es que se puede cometer en su repo de el /proveedor. De hecho, el compositor crea una segunda remoto llamado «compositor» para cada paquete (o paquetes) que hace referencia a la repo del paquete, a fin de que usted puede trabajar en ello en un contexto de trabajo.
    Así que la buena práctica es registrar su paquete en su compositor.json para todos sus proyectos y comprometerse desde su /vendor/MyCompany/MyBundle, de cualquier proyecto.

    Como una prueba, sólo tiene que ejecutar git remote -v de cualquier paquete en su proveedor.

    La mala práctica sería considerar la posibilidad de su paquete como un proyecto independiente y tiene enlaces simbólicos con ella. La razón principal de esto es la mala práctica es que usted no será capaz de declarar a dependencias con su paquete. Además tendrás algunas dificultades con la implementación de sus proyectos.

    • Estoy creando propio proveedor del Paquete. Quiero poner este paquete por ejemplo en GitHub y utilizarlo en otros proyectos. Me debe generar un nuevo Bundle en /src o en /vendor directorio de inicio? Cuando me incluyen en este Paquete a otro proyecto será en /vendor pero donde debo genate ellos en el inicio?
    • Crear un nuevo proyecto vacío en GitHub que se va a almacenar su paquete. Cometer un compositor.json en ella. Incluso puede cometer un muy simple compositor.json, con sólo el nombre y la descripción de su paquete. De vuelta en su proyecto, agregue un requisito para su nuevo paquete y hacer un composer update. Ahora usted debería ver a su lote vacío en el proveedor de la carpeta y usted puede trabajar en ella. Si usted desea que su paquete sea pública, agregarlo a Packagist.
  3. 3

    En Symfony4, generate:bundle comando no está disponible. En su lugar, usted puede seguir este tutorial.

    Primero crear un proyecto con:

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

    A continuación, cree un my-project/lib/AcmeFooBundle/src directorio. Aquí viven su paquete. El espacio de nombres para este directorio será Acme\AcmeFooBundle, por lo que si se crea una clase de servicio en lib/AcmeFooBundle/src/Service/Foo.php, su espacio de nombres sería Acme\AcmeFooBundle\Service.

    Ahora tenemos que decirle compositor cargador automático para buscar nuevas clases en que el nuevo directorio, así que tenemos que editar composer.json autoload sección:

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

    y ejecutar composer dump-autoload.

    Ahora sólo necesita agregar a su paquete de clase a config/bundles.php:

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

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

    Si quieres comprobar tus servicios antes de la adición de la inyección de dependencia, sólo puede autowire ellos en config/services.yml:

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

    Eso es todo. Siga las mejores prácticas y de ir en la codificación.

    PS: he publicado un post con un par de consejos para el desarrollo de Symfony reutilizables haces.

    • muchas gracias por esta actualizado el tutorial 🙂

Dejar respuesta

Please enter your comment!
Please enter your name here