Estamos usando hilo para todas nuestras instalaciones de paquetes deterministas, pero no evitamos que el usuario use npm; sin embargo, supongo que tener ambos archivos causará problemas. ¿Debería agregarse uno a su directorio .gitignore?

Confirme siempre los archivos de bloqueo de dependencia en general

Como se explica en otra parte, los archivos de bloqueo de dependencia, que son compatibles con muchos sistemas de administración de paquetes (por ejemplo: compositor y empaquetador ), deben comprometerse con la base de código en proyectos de fin de cadena, de modo que cada individuo que intente ejecutar ese proyecto esté funcionando así que exactamente con el conjunto probado de dependencias.

Es menos claro si los archivos de bloqueo siempre deben confirmarse en paquetes que están destinados a incluirse en otros proyectos (donde se desean dependencias más flexibles). Sin embargo, tanto Yarn como NPM (como lo cubre @Cyrille) ignoran inteligentemente yarn.locky package-lock.jsonrespectivamente cuando sea necesario, lo que hace que sea seguro confirmar siempre estos archivos de bloqueo.

Por lo tanto, siempreyarn.lockpackage-lock.json debe confirmar al menos uno de o según el administrador de paquetes que esté utilizando.

¿Debería confirmar tanto yarn.lock como package-lock.json?

En la actualidad tenemos dos sistemas de administración de paquetes diferentes, que instalan el mismo conjunto de dependencias desde package.json, pero que generan y leen desde dos archivos de bloqueo diferentes. NPM 5 genera package-lock.json, mientras que Yarn genera yarn.lock.

Si se compromete package-lock.json, está construyendo soporte para las personas que instalan sus dependencias con NPM 5. Si se compromete yarn.lock, está construyendo soporte para las personas que instalan dependencias con Yarn.

Si elige comprometerse yarn.locko package-lock.jsonambos depende de si los que desarrollan en su proyecto solo están usando Yarn o NPM 5 o ambos. Si su proyecto es de código abierto, lo más amigable para la comunidad probablemente sería comprometer ambos y tener un proceso automatizado para garantizar yarn.locky package-lock.jsonestar siempre sincronizados.

Actualización: Yarn ha introducido un importcomando que generará un yarn.lockarchivo a partir de un package-lock.jsonarchivo. Esto podría resultar útil para mantener sincronizados los dos archivos. (Gracias @weakish)

Este tema se discutió extensamente en el proyecto Yarn en:

• "Idea: soporte package-lock.json de npm 5"
• "Los archivos de bloqueo de la competencia crean una mala experiencia de usuario"

Ambos están ahora cerrados.

Debe confirmar 1 archivo de bloqueo del árbol de dependencias, pero no debe confirmar ambos. Esto también requiere estandarizar en yarn o npm (no en ambos) para construir + desarrollar un proyecto.

Aquí está el artículo de hilo sobre por qué se debe realizar yarn.lock, si se estandariza en hilo.

Si confirma tanto el yarn.lockarchivo como los archivos, package-lock.jsonhay muchas formas en que los 2 archivos pueden proporcionar diferentes árboles de dependencia (incluso si los algoritmos de resolución de árbol de yarn y npm son idénticos), y no es trivial asegurarse de que proporcionen exactamente el misma respuesta. Dado que no es trivial, es poco probable que se mantenga el mismo árbol de dependencias en ambos archivos, y no desea un comportamiento diferente dependiendo de si la compilación se realizó usando yarn o npm.

Si y cuando yarn cambia de usar yarn.locka package-lock.json( problema aquí ), entonces la elección del archivo de bloqueo para confirmar se vuelve fácil, y ya no tenemos que preocuparnos por yarn y npm que resulten en compilaciones diferentes. Según esta publicación del blog , este es un cambio que no deberíamos esperar pronto (la publicación del blog también describe las diferencias entre yarn.locky package-lock.json.

Estaba pensando en la misma pregunta. Aquí están mis pensamientos, espero que ayude:

La documentación de npm package-lock.json dice lo siguiente:

package-lock.json se genera automáticamente para cualquier operación en la que npm modifique el árbol node_modules o package.json. Describe el árbol exacto que se generó, de modo que las instalaciones posteriores pueden generar árboles idénticos, independientemente de las actualizaciones de dependencia intermedias.

Esto es genial porque evita el efecto "funciona en mi máquina".

Sin este archivo, si usted npm install --save A, npm se agregará "A": "^1.2.3"a su package.json. Cuando alguien más ejecuta npm installsu proyecto, es posible que se haya lanzado la versión 1.2.4de A. Dado que es la última versión disponible que satisface el rango semver especificado en su package.json, instalará esta versión. Pero, ¿qué pasa si se introduce un nuevo error en esta versión? Esta persona tendrá un problema que no podrás reproducir porque tienes la versión anterior, sin ningún error.

Al arreglar el estado de su node_modulesdirectorio, el package-lock.jsonarchivo evita este problema porque todos tendrán las mismas versiones de todos los paquetes.

Pero, ¿qué pasa si está escribiendo y publicando un módulo npm? La documentación dice lo siguiente:

Un detalle clave sobre package-lock.json es que no se puede publicar y se ignorará si se encuentra en cualquier lugar que no sea el paquete de nivel superior.

Entonces, incluso si lo confirma, cuando el usuario instale su módulo, no obtendrá el package-lock.jsonarchivo, sino solo el package.jsonarchivo. Por lo tanto, npm instalará la última versión que satisfaga los rangos semver de todas sus dependencias. Significa que siempre desea probar su módulo con estas versiones de sus dependencias, y no con la que instaló cuando comenzó a escribir su módulo. Entonces, en ese caso, package-lock.jsones claramente inútil. Más, puede resultar molesto.

Esta es mi regla general: si está trabajando en una aplicación, confirme los archivos de bloqueo. Si mantiene una biblioteca, agréguela a su lista ignorada. De cualquier manera, debería utilizar rangos semver precisos enpackage.json . Yehuda Katz ( almacenado en caché ) escribió una gran explicación sobre cuándo confirmar Gemfile.lock(archivo de bloqueo de Ruby) y cuándo no. Al menos lea la sección tl; dr.

¡Estás en lo correcto! Permitir que se usen ambos npmy yarnva a causar problemas. Echa un vistazo a este artículo .

Actualmente, planeamos agregar algunas advertencias a los usuarios que usan ambos yarn y npmen el mismo repositorio para instalar paquetes.

Le recomendamos que elimine el package-lock.jsonarchivo si decide usar hilo para evitar futuras confusiones y posibles problemas de consistencia.

Es posible que no desee ambos npmy yarncomo administrador de paquetes.

Estos archivos son administrados por sus herramientas, por lo tanto, suponiendo que el uso de hilo actualizará efectivamente el package-lock.json , supongo que confirmar ambos archivos funciona bien.

Creo que lo más importante para tu usuario es package-lock.json(yo, por ejemplo, no uso hilo), así que este tiene que estar comprometido.

Para el yarn.lock, depende de si trabajas solo o en equipo. Si es solo, supongo que no hay necesidad de cometerlo. Si (planea) trabajar en equipo, entonces probablemente debería comprometerse, al menos hasta que el hilo lo respalde 🙂

Supongo que el equipo de hilo eventualmente dejará de usar yarn.locky usará package-json.locken su lugar, en este momento será más simple 😛

No, el uso de ambos archivos de bloqueo simultáneamente dará lugar a inconsistencias en su árbol de dependencia, especialmente cuando se colabora en un equipo. Ignorar una cerradura u otra es una solución sencilla. Solo asegúrese de que su equipo comprenda y esté de acuerdo con este cambio.