publicando un package de bower (¿con bower?)

La web está llena de ejemplos de cómo consumir packages por bower, pero le falta un simple recorrido sobre cómo registrar / implementar / publicar (cualquiera que sea el término que prefiera) packages.

Supongamos que estoy desarrollando mi propio package js, ¿cómo puedo implementarlo en un repository / carpeta privada ? ¿Debo usar Bower en absoluto para ese propósito? ¿O debería usar tareas gruñonas?

Permítanme ser más preciso sobre lo que necesito: me gustaría crear un proyecto js, ​​que consum otros packages de bower. Me gustaría concatenar docenas de files js en uno o varios files js (cada uno destinado a ser un package de bower), eliminarlos, minimizarlos, probarlos y romper sus huesos, y simplemente implementar cada uno de los files js finales. en un repository (en mi caso, SVN, porque eso es lo que usamos en nuestra empresa).

Por mucho que cavo en la web, me parece que esta no es una tarea para bower, es una tarea para grunt / ant. ¿Estoy en lo cierto?

Un poco tarde, pero actualmente estoy tratando de descubrir muchas de las mismas cosas. Esto es lo que descubrí hasta ahora.

  • Utilizaría ronco para build sus bibliotecas, colóquelas en una carpeta de distribución. Esto manejaría todas las pisadas / minificación / concatenación, etc.
  • Cuando esté listo para el horario de máxima audiencia, cree una label para él en svn. (Ver abajo … esto es un poco raro).
  • No necesita registrar nada. Simplemente use la installation con la ruta al repository.

    bower install svn + https://svn.mycompany.com/myproject

  • Utilice las opciones –save o –save-dev para savelo en su file bower.json.

  • Puedes golpear a SVN de varias maneras:

    • Un punto final remoto público de Subversion, por ejemplo, svn + http://package.googlecode.com/svn/ .
    • Un repository privado de Subversion, por ejemplo, svn + ssh: //package.googlecode.com/svn/.
    • Un punto final local, es decir, una carpeta que es un repository de Subversion, por ejemplo, svn + file: /// path / to / svn /.

Esto es de la página de inicio de Bower .

Por supuesto, no es tan fácil. Algunos más que he descubierto:

Lo que sea que coloques como ruta al repository SVN debe tener tres carpetas debajo: tronco, twigs y tags. Por lo tanto, está completamente bien apuntar a alguna subcarpeta, pero debajo de eso, debe tener estas tres carpetas. Es decir, digamos que tiene una carpeta de distribución debajo de su carpeta principal (es decir, / trunk / dist). Tienes un gruñido al poner el producto final en esta carpeta. Luego lo label (copy el tronco a las tags). Entonces su estructura de directorys se vería así:

myproject\tags\REL-1.0\dist\my-library.js 

Con esta estructura, bower es vómito, si tratas de hacer algo como

 bower install https://svn.mycompany.com/myproject/tags/REL-1.0/dist 

Ahora, si haces esas tres carpetas bajo dist, funcionará. Es decir, si la estructura de la carpeta se veía así:

 myproject\tabs\REL-1.0\dist\tags\my-library.js 

el command de bower anterior funcionaría (pero eso es realmente feo).

Debido a esto, es probable que necesite tener un repository separado para sus packages. Ah, y sea cual sea la última carpeta en la ruta, esa será la carpeta en la carpeta del proveedor después de que bower la instale. Es decir, en el ejemplo anterior, la biblioteca estará en la carpeta vendors \ dist … no es ideal. Por lo tanto, actualmente estoy viendo algo como esto:

 mypackages/MyLibrary/tags/REL-1.0 

Entonces, el repository es mypackages, hay una carpeta para cada biblioteca. Debajo de eso están las tres carpetas requeridas (tronco, etc.). Luego tengo carpetas debajo de las tags para cada lanzamiento.

Puede observar la carpeta de esta manera:

 bower install svn+https://svn.mycompany.com/mypackages/MyLibrary#REL-1.0 

Y puedes usar #trunk para get el trunk. Algo raro. Si no proporciona ninguna versión (carpeta), obtiene la última carpeta de las tags (no estoy seguro si eso se hace por order de sorting o en la date de confirmación). Si no hay carpetas en las tags, obtiene el tronco. No estoy seguro de cómo llegar a cualquier cosa en las twigs.

Además, si tiene security en su repository, si ha guardado la información de authentication, simplemente funcionará. No tengo idea de cómo funcionaría eso si no tienes guardada la información de authentication.

¡Espero que esto ayude! Todavía estoy descifrándome …

He progresado mucho en las últimas semanas y estoy feliz de compartir mis hallazgos con los novatos gruñones y bower como yo.

Parece que Bower se registra de forma pnetworkingeterminada en el logging http://bower.herokuapp.com , que solo es compatible con el protocolo git (ya que está destinado a las bibliotecas públicas del server).

Entonces, si desea publicar sus propias bibliotecas js en repositorys privados, usar el logging pnetworkingeterminado no es una buena práctica. Hay muchas implementaciones de logging de bower por ahí. Personalmente, soy un chico de Java, así que en mi patio de recreo utilicé https://github.com/Softpagehomeware/bower-java-registry , pero también hay npm, python y otras implementaciones de logging.

Cuando desee consumir su package en otro proyecto, simplemente defina dónde searchlo en su file .bowerrc:

 { "registry": { "register": "http://myhost/bower-java-server", "publish": "http://myhost/bower-java-server", "search": [ "http://myhost/bower-java-server" , "https://bower.herokuapp.com" ] }, "directory": "bower_components" } 

De esta manera, cuando tiene una dependencia de bower, primero busca en su logging privado, y si no lo encuentra, busca el logging de herokuapp.

En cuanto a alojar el package de distribución en mi repository git privado, he usado grunt-build-control , que puede llevarlo a la carpeta dist y enviarlo a su repository distribuible (que está registrado en el logging de su bower).

    Intereting Posts