1. Surge el problema
Por casualidad, descubrí que hay package-lock.json en el almacén de códigos de la empresa, sdk build y reactjs build warehouse. Estos dos archivos deben generarse en tiempo de compilación. Para mí con OCD, naturalmente no puedo soportarlo. Tan decisivamente un MR, eliminó estos dos package-lock.json. Sigo siendo complaciente pensando que he hecho una buena acción, pero no sé si esto me ha traído un mal posicionamiento durante dos días ...
Dos, proceso y solución
El día de la integración de MR, el almacén de la base de la sucursal principal 21.0 no se pudo construir. El jefe de CIE me encontró y me dijo que había un problema con la construcción del almacén de la base del front-end. Me sorprendió. Inmediatamente miré el MR fusionado ese día y descubrí que podría afectar la construcción. Lo único en el proceso es mi MR que elimina package-lock.json. Primero calme y mire el registro de errores dado:
npm ERR! Unexpected end of JSON input while parsing near '...l.com"}],"directories'
npm ERR! A complete log of this run can be found in:
npm ERR! /Users/louyanping/.npm/_logs/2018-12-14T03_32_00_994Z-debug.log
louyanpingdeMacBook-Pro:cnpc_group_buying louyanping$
Sí, no hay otro mensaje de error, solo esta frase vaga. En ese momento, la línea de montaje era urgente, y sin considerar los detalles, directamente creamos una sucursal y restauramos las eliminadas package-lock.json. Primero, piense en garantizar el proceso de construcción y luego considere el problema.
Después de que se cargó la biblioteca, inesperadamente, el mensaje de error anterior aún aparecía. En ese momento me di cuenta de la gravedad del problema.
Hace dos días, escuché a la persona a cargo de CIE decir que el entorno de la máquina puede cambiar. Para eliminar la causa del cambio del entorno de la máquina de envasado, a través del tiempo de la biblioteca mr, averigüe el último almacén base construido con éxito, vuelva al envío y envíe a un nuevo Rama para construir. Descubrió que se puede construir con éxito, lo que elimina el problema del entorno de la máquina.
Combinando el hecho de que el proceso de compilación del día anterior a CIE era normal y el problema se produjo después de que se cargó la biblioteca, el problema básicamente se puede ubicar porque el código se cargó en la biblioteca. Verifiqué el MR de la biblioteca ese día y confirmé que solo cambié el relacionado con la compilación Después del proceso, se determinó que yo era package-lock.jsonel motivo de la eliminación de la base de datos .
Entonces ahora viene el problema. El código que cargué en la biblioteca causó un problema y no funcionó después de la restauración. ¿Cuál podría ser el problema?
缓存Esta es la primera palabra que me viene a la mente. Como package-lock.jsonenvié más tarde , no se puede restaurar debido a la falta de package-lock.json, algunas cosas almacenadas en caché en el proceso de compilación, en otras palabras, porque no hay package-lock.json, la máquina de compilación hizo algunos procesos no convencionales al instalar paquetes dependientes. Se actualizaron los paquetes dependientes en el paquete de caché anterior. Entonces pensé en una solución para borrar la caché npm.
Ejecútelo en la máquina de compilación npm cache clean --force, borre el caché del paquete descargado anteriormente, vuelva a compilar y descubra que el error anterior desapareció, pero se reemplazó por otro error.
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:5:45
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:9:18
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:10:18
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:11:18
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/fs.d.ts[39m:12:22
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/process.d.ts[39m:8:27
03:06:13 TS2304: [31mCannot find name 'bigint'.[39m
03:06:13
03:06:13 ERROR in [at-loader] [31m./node_modules/@types/node/ts3.4/util.d.ts[39m:6:56
03:06:13 TS2304: [31mCannot find name 'BigInt64Array'.[39m
03:06:13
¡Demuestra que mi idea es correcta! El caché provoca el cambio de la estrategia de instalación del paquete para el proceso de compilación. Una vez que se borra el caché, se cambia la estrategia de instalación del paquete. Se adopta el paquete descargado de acuerdo con las últimas regulaciones en package.json, pero algunas bibliotecas del paquete recién descargado entran en conflicto con las bibliotecas del caché. , Resultando en un error!
De acuerdo con el mensaje de error, navegar a está jssdken algún otro módulo que hace referencia a TypeScriptlas bigintnuevas funciones, la intuición me dice que esto se debe ciertamente a versiones incompatibles de plomo. Actualmente package.jsonen TypeScriptla versión 3.0.2, tan decisiva TypeScriptdel sitio web oficial de Shang , buscaba registros de actualizaciones y comprobó que las bigintcaracterísticas son 3.2compatibles con la versión posterior. Entonces, la TypeScriptversión mejorada es 3.8.3compilar nuevamente y el problema finalmente se resuelve.
Tres, resumen
Después de someterse a la biblioteca MR, dio un suspiro de alivio. Este asunto se resuelve temporalmente aquí, pero el problema causado por enviar package-lock.json es tan serio que no puede evitar relajarse. Mirando hacia atrás en la aparición de todo el problema, el proceso es el siguiente:
- Cierto desarrollo presentado el 21 de febrero de 2020.01,
package-lock.jsony el documento aún no se ha presentado - En los últimos 8 meses, las bibliotecas de dependencia de front-end se han actualizado varias veces.
- De hecho, usamos la
package-lock.jsonruta de la caché de dependencia especificada en la compilación durante este período . Incluso si actualizamos algunas versiones de la biblioteca, seguimos usando la ruta de la dependencia en la caché y el servidor no la volvió a descargar. Por ejemplo, la "cierta biblioteca" en este ejemplo, por ejemplo, llamadalibA, en enero de 2020, es la1.0.0versión y solo necesitatypeScript 3.0.2satisfacer la demanda. Pero en mayo, se actualizó y se convirtió en una biblioteca1.2.0que debetypescript3.2.0admitir bigint para funcionar. Sin embargo, debido a la existenciapackage-lock.jsonde la biblioteca, la biblioteca descargada todavía está en la caché1.0.0. Enpackage-lock.jsonel caso de los archivos, el proceso de construcción no será un problema, porque todos no han cambiado, por lo que las dependencias de la biblioteca no se han actualizado en absoluto. Esto no es más que una enterrada. Una bomba de tiempo , esperando a que alguien pise ... - Esa persona soy yo. Después de que eliminé la biblioteca
package-lock.json, se abrió la puerta del diablo y apareció el problema de la incompatibilidad de dependencia ...
Esta cosa nos dice package-lock.jsonla importancia del mantenimiento. Después de consultar la información relevante, descubrí que en realidad se package-lock.jsonrecomienda cargar la biblioteca. Es terrible que hayamos cargado la biblioteca. Las actualizaciones posteriores de la versión no enviaron package.lock.json sincrónicamente . Incompatibilidad de dependencia causada.
Cuarto, una descripción detallada del proceso de instalación de npm
Se recomienda un buen artículo aquí: https://mp.weixin.qq.com/s/5tmND0G_ZkYVR7Dmug0ugQ
solo un vistazo, no hay tiempo para aprender en detalle, tendré tiempo para aprender en detalle y reimprimirlo.