NodeJS y NPM: problemas siguientes recomendación para comprobar módulos en git

Question

estoy teniendo problemas para seguir la recomendación 'oficial' para comprobar en todas las dependencias externas en Git (artículo http://www.mikealrogers.com/posts/nodemodules-in-git.html vinculados FAQ Fron)

1. ¿Cómo ¿se asegura de que no solo las dependencias de nivel superior estén registradas? La mayoría de los módulos npm actualmente no siguen la recomendación. Todos tienen sus node_modules en .gitignore. Solo borrar su .gitignore parece arriesgado.

2. Para el módulo compilado, el artículo recomienda registrar solo las fuentes y ejecutar 'npm Rebuild' e implementar el tiempo. Desafortunadamente 'reconstrucción de npm' no hace una 'versión limpia' para todos los módulos (a pesar de que la corrección de errores https://github.com/isaacs/npm/issues/1872 está incluida en la versión 1.0.106 de npm que estoy usando). Esto significa que tengo que evitar que se registren los objetivos de compilación (de lo contrario, habría compilado el código del objeto para la máquina del desarrollador en la máquina de producción sin que la reconstrucción de npm lo sobrescriba). Pero: ¿cómo hago esto? Lamentablemente, los módulos no tienen un directorio común de salida de compilación, así que simplemente ignorando git "node_modules//build" y "/ node_modules//out /" (como se menciona en este artículo bueno eng.yammer.com/blog/ 2012/1/4/Gestión-nodejs-dependencias-y-despliegues-en-yammer.html no ayudarán en todos los casos

versión corta:. ¿cómo asegurarse de que los servidores de producción utilizan la exacta la misma versión de todos los módulos dependientes que usa durante el desarrollo?

Answer 1

ACTUALIZACIÓN: ahora hay npm shrinkwrap que resuelve el problema de bloquear las versiones de dependencia exactas, incluso de la dependencia de las dependencias ¡sí! More info here.

El registro node_modules puede ser problemático, ya que el ambiente que se está ejecutando en espera puede variar de usuario a usuario - así que lo que se compila en algún ambiente puede no funcionar en otro. Además, llenaría sus registros de cambios y repositorios con código de terceros. Lo que considero es la conspiración a la que has llegado con tu versión corta de la pregunta, así que déjame abordar eso.

Versión corta: ¿cómo se asegura de que los servidores de producción utilicen la misma versión exacta de todos los módulos dependientes que usa durante el desarrollo?

Dentro de su package.json, habrá dependencies: {}, si no está allí, entonces agregarlo. Para lograr lo que desea, agregue sus dependencias como clave y sus versiones exactas como valor. P.ej. dependencies: { docpad: '2.5.0', mocha: '1.1.0' }

Sin embargo, en general (depende del autor) las actualizaciones al número de revisión (el número x.x.X) son correcciones de errores y son seguras. Puede permitir cambios menores haciendo dependencies: { docpad: '2.5.x', mocha: '1.1.x' } que le ahorra tener que actualizar su package.json y hacer un lanzamiento cada vez que hay una versión de corrección de errores. Incluso puede hacer cosas como 2.x si lo desea.

Esta es la solución que he venido a utilizar para todos mis módulos, ya que garantiza que incluso 6 meses después o lo que sea que el módulo funcione, mientras que hacer algo como >= 2.0.0 significa que aparece v3 de una dependencia, su módulo probablemente será inutilizable en ese momento. Asegurarte que te apegas a versiones específicas "garantiza" la estabilidad en el tiempo.

For reference you can see how I've done it in my open-source node.js modules here

Answer 2

Sobre el .gitignore de sus dependencias (en "node_modules"), la NGP 1.1 ignora los archivos .gitignore, de modo que no se instalan;

npm 1.1 will exclude .gitignore files from the things it installs. 
npm 1.0 did not have this feature, so you have to be careful about that. 
Deleting them recursively is fine: 
    find node_modules -name .gitignore | xargs rm 
But, in npm 1.1, you never have to do this, because it excludes them 
from the install automatically. 

que viene desde el mismo jefe (Isaac), y it's here y parece que cubre prácticamente todo. El problema "extraño" que tengo debe ser algo tonto que he hecho, intentaré una configuración limpia.