nodejs, github, npm y enlaces simbólicos

Tengo un proyecto nodejs con algunas dependencies en mis propios modules. según las mejores prácticas actuales de npm, esas dependencies se representan utilizando los npm link / npm link $package-name , por lo que el proyecto ahora tiene algunos enlaces simbólicos en sus node_modules . localmente que funciona.

Sin embargo, cuando envío ese proyecto a github, los enlaces se conservan como enlaces, lo que significa que otras personas que lo clonarán (muy probablemente) verán enlaces rotos. otro punto es que llevo el directory node_modules a github, está bien hasta ahora la clonación desde github ahora te da una instancia completa del proyecto con todas las dependencies resueltas, pero por otro lado de repente tengo muchas cosas de terceros. en mi repository.

¿Cuál es la mejor práctica para lidiar con este tipo de situación?

edito una cosa que me acabo de dar count es que el control de las dependencies como código instalado es incorrecto de todos modos, puede haber algunos binarys involucrados que necesiten instalarse de una manera específica de la plataforma. entonces nunca revisas tus dependencies?

No incluya el directory node_modules en su repository de origen. Git es para el código fuente , no distribuciones construidas. Esa es la mejor práctica como lo ha sido durante décadas. Ignora los hipsters que ves ocasionalmente poniendo artefactos de construcción en git. Están equivocados, simplemente no han sentido el dolor lo suficiente como para darse count. Además de ser incorrecto desde una perspectiva de metodología de sonido, include tus node_modules en git fallará cuando (no si) tu proyecto incluye extensiones con componentes C que se comstackn por plataforma. Esto no requerirá al less una npm rebuild por parte del usuario que clonó el repository para arreglarlo, y en ese momento también podría hacer que hagan la npm install como $Deity previsto.

Primero, no incluya otros modules de nodos en su proyecto git

 cd ~/your_module && echo "/node_modules" >> .gitignore 

En segundo lugar, si su module tiene dependencies, solo debe declararlas en su package.json . package.json . Aquí hay un ejemplo de mi module burro

 // package.json { // ... "devDependencies": { "mocha": "~1.8.1", "hiccup": "~0.1.4" }, "dependencies": { "bun": "~0.0.5" } } 

Por lo que vale, en realidad no uso la npm link ; Construyo / pruebo todos mis modules por separado. Hay un buen puñado de ellos que puedes ver en mis repositorys de Github si quieres otros ejemplos.

Mi flujo de trabajo básico es este:

  1. module de parche A
  2. versión de choque en el module A
  3. npm publish module A
  4. dependencia de la versión de testing del module A en el module B
  5. volver a npm install module de npm install A en el module B
  6. modifique el module B para que funcione con la nueva versión del module A (si es necesario)
  7. versión de choque en el module B
  8. npm publish module B

npm link es útil, pero creo que habilita / fomenta un acoplamiento demasiado ajustado entre sus modules. Creo firmemente en el mantra de "hacer una sola cosa y hacerlo bien" y tener esto en count al crear todos mis modules. El uso de este flujo de trabajo ayudará a mantener su funcionalidad bien encapsulada y la comunidad amará sus lanzamientos.


En cuanto a la parte de Github, a la npm realmente no le importa esto. Como un hábito, antes de que npm publish un lanzamiento, siempre labelré ese compromiso con la versión del module. Aquí hay un ejemplo

  1. establecer la versión a "0.1.5" en package.json
  2. git commit -m "bump to version 0.1.5"
  3. git tag v0.1.5
  4. git push origin master --tags
  5. npm publish

Ahora tanto npmjs.org como github.com están de acuerdo en la misma versión. Los usuarios que descarguen su package desde cualquier fuente siempre obtendrán lo mismo.