javascript - node - npm

Yarn: procedimiento para volver a implementar las dependencias de JavaScript en el servidor de producción(uso del archivo `yarn.lock`)

Question

He leído la documentación en Yarn, y sé que el archivo de lock debe estar comprometido con VC. ¡Vea this y explique en un alto nivel por qué es necesario el archivo de bloqueo, y this enumera un montón de comandos sin mucha explicación de lo que realmente hacen!

También he leído muchas preguntas en StackOverflow que preguntan si el archivo de lock debe confirmarse en VC.

Sin embargo, toda la documentación y los subprocesos SO parecen pasar por alto los detalles que quiero saber, que son los siguientes; ¿Cuál es el procedimiento correcto (el grupo correcto de comandos a ejecutar) para:

1. Actualizar el archivo yarn.lock cuando lo necesito (es decir, en el entorno de desarrollo donde deseo extraer las últimas versiones secundarias y actualizar el archivo de lock para reflejar esto)
2. Para mantener mi archivo de bloqueo sincronizado con otros desarrolladores para garantizar que se están desarrollando / probando desde las mismas versiones de dependencia, y
3. Para actualizar / volver a sincronizar el directorio node_modules en el servidor de producción (es decir, para asegurarse de que el servidor de producción no se ejecute en una versión diferente o de última hora de los paquetes dependientes)

Le pregunto en parte porque en el pasado, mientras realizaba un git pull en el servidor, me encontré con mensajes que me dicen que el archivo yarn.lock se ha actualizado independientemente del proceso de desarrollo / VC. En lo que a mí respecta, esto nunca debe permitirse que suceda.

Answer 1

1. Sinceramente, esta es una cuestión de opinión / preferencia. He visto algunas estrategias:

   • Utilizando yarn upgrade
   • Realizando manualmente la versión en package.json antes de ejecutar el yarn

2. Como mencionó Fabien: usar la yarn check

3. Puede usar los espejos fuera de línea sin hilos donde confirma los cachés de sus paquetes npm en el control de versiones. (Ver this artículo mediano)

   Además, hay un montón de ventajas cuando se utiliza yarn --offline - yarn --offline :

   • Las compilaciones son más rápidas porque no tiene que obtener paquetes del registro de npm.
   • Sus compilaciones fallarán si no tiene las dependencias correctas.

Answer 2

La siguiente información se basa en lo que usamos diariamente en Orange, esto puede no ser la única verdad.

1) Actualizando yarn.lock

yarn upgrade [package | package@tag | package@version | @scope/]... [--ignore-engines] [--pattern]

Este comando actualiza las dependencias a su última versión en función del rango de versiones especificado en el archivo package.json . El archivo yarn.lock también será recreado.

fuente: https://yarnpkg.com/en/docs/cli/upgrade

2) Dependencia entre desarrolladores.

Lo que sugiero que haga es crear un script que verifique la versión actual "recomendada" para tener con la ayuda de:

yarn check

Verifica que las versiones de las dependencias del paquete en el package.json del proyecto actual coincidan con las del archivo de bloqueo del hilo.

fuente: https://yarnpkg.com/en/docs/cli/check

3) Actualización de la producción del servidor.

Lo mismo que 2) usando un script de git hook, debería ayudarlo a yarn check si la versión package.json es correcta si no inicia una yarn update .