Heroku-buildpack-nodejs: Limpieza de caché

Una forma de borrar el caché sería excelente, a un cliente también le gustaría una función de "actualización de npm" ... no estoy seguro de cómo podemos admitir eso, pero si pudiera borrar el caché, al menos podría volver a instalar su paquetes

¡Este es realmente un problema bastante serio!

Por ejemplo, si construyo una aplicación que depende de express solo en package.json, mis node_modules se verán así:

--> expreso
--> conectar

Si luego decido que necesito acceso directo para conectarme desde mi aplicación de vez en cuando, lo agregaría a package.json, y luego mis módulos de nodo se verían así:

--> expreso
--> conectar
--> conectar

¡Express ahora usa una instancia de conexión diferente a la de mi aplicación! Sin embargo, si hiciera un npm rebuild localmente, o clonara la aplicación de nuevo y comenzara con un npm install nuevo, terminaría así:

--> expreso
--> conectar

Express subiría automáticamente al árbol para usar la misma instancia de conexión.

Normalmente, esta es una diferencia menor y no será un problema, pero puede haber errores muy sutiles. Por ejemplo:

1) Express depende de, por ejemplo, connect >= 1.0.1. Entonces su copia de connect será 1.0.1. Si luego actualizo connect en mi aplicación, podría obtener 1.0.2, pero express seguirá usando 1.0.1. Por lo tanto, las funciones de 1.0.2 no estarán disponibles a través de Express, ¡y no hay forma de actualizarlo!

2) Si connect almacena algunas propiedades de instancia en sí mismo, no estarán disponibles en ambos lugares. En el caso de connect, en realidad hace esto con la colección connect.bodyParser.parsers , que es actualizable por el usuario para agregar analizadores de solicitudes adicionales según el tipo (por ejemplo, agregar soporte para solicitudes formateadas 'application/lolcats').

Sin una forma de forzar una reconstrucción de sus node_modules, se quedará atrapado en este tipo de infierno NPM, donde las versiones precisas de sus diversos módulos y dónde están ubicados están determinados por su paquete de nivel superior combinado con su historial de actualizándolo y subsiguientes impulsos a heroku. Idealmente, se generaría de forma determinista basándose únicamente en el estado de package.json en un momento determinado, no en función de una serie de actualizaciones incrementales imposibles de rastrear.

¡Agregue una opción para forzar un npm rebuild en lugar de un simple npm install ! Gracias :)

Acabo de descubrir una solución temporal. Modifiqué este paquete de compilación en mi propia bifurcación para usar npm rebuild , en lugar de npm install . Es posible cambiar la URL del paquete de compilación en una aplicación existente, aunque no pude encontrar esto documentado en ninguna parte. Por lo tanto, para hacer esto de forma única, puede apuntar su aplicación a mi versión modificada del paquete de compilación, ejecutar una implementación y luego apuntarla de nuevo.

$ heroku config:add BUILDPACK_URL=https://github.com/bcherry/heroku-buildpack-nodejs
$ git push heroku master
$ heroku config:remove BUILDPACK_URL

Pero aún sería muy útil tener esto disponible como una opción en la implementación, o quizás a través de heroku cli. Tal como están las cosas, no podemos ejecutar npm rebuild a través heroku run , aunque puede ejecutar node a través heroku run , por lo que tal vez npm solo necesite estar disponible ¿allí?

@bcherry Lamentablemente, los cambios realizados en el sistema de archivos en una sesión heroku run no son permanentes. npm rebuild podría ser la mejor solución, pero haría que su aplicación se volviera a compilar en cada inserción, lo que tampoco es deseable. Aún así, podría ser mejor que el statu quo.

He estado usando la reconstrucción de npm a través de mi paquete de compilación personalizado y, aparte del volumen adicional de salida, no he encontrado que agregue mucho tiempo al proceso de implementación. No es lo mismo que rm -rf node_modules && npm install , definitivamente funciona mucho menos.

Ah, guay. ¿Funciona rebuild en una instalación nueva también? Si es así, enviaría una solicitud de extracción larga para cambiar install a rebuild .

Sabes, ahora que estoy buscando un poco más, parece que malinterpreté un poco 'reconstruir'. Simplemente vuelve a compilar los paquetes que necesitan compilación, por ejemplo, si actualizó node. Por lo tanto, no está claro que solucione los problemas del árbol de dependencia. Sin embargo, en la práctica descubrí que usarlo en mi aplicación solucionó un problema de dependencia que no estaba con un paquete compilado, por lo que no estoy seguro de por qué. Pero parece que en realidad sería necesario hacer npm install y npm rebuild , en lugar de solo reconstruir. Lo investigaré un poco más y actualizaré si encuentro una solución razonable y completa para este problema.

El manejo de npm ha cambiado bastante en las últimas versiones del paquete de compilación. Por favor, avíseme si todavía tiene problemas.

Puede o no ser el lugar correcto para mencionar esto, pero tengo un problema muy similar con mi compilación personalizada de Python: creo que es un problema general de la plataforma Heroku, no específico de ningún paquete de compilación en particular. Mantener el caché correcto es una necesidad en todos los buildpacks; al igual que permitir a los desarrolladores del paquete de compilación borrar el caché (por ejemplo, cuando la semántica del caché sigue siendo incorrecta porque estoy pirateando el paquete de compilación...).

Dado que esto ya no está relacionado con ningún paquete de compilación en particular, no estoy seguro de dónde tomar esto. ¿El paquete de compilación de Python? ¿Aquí? ¿Una lista de correo? [email protected] (probablemente la peor opción, ya que no es público...).

Estoy viendo este problema también. Estoy agregando dependencias a package.json, presionando, luego eliminando las dependencias y presionando nuevamente. Heroku parece instalar las antiguas dependencias también, lo que parece un desperdicio...

Tengo un problema similar con un heroku-buildpack-php personalizado para Laravel. Lo compilé después de darme cuenta de que necesitaba exportar la RUTA, y luego, una vez que se ejecutó el script Laravel, noté que mi php.ini no habilitaba pdo_pgsql, así que agregué la extensión y ahora el paquete de compilación no se vuelve a compilar.

Pude borrar el caché simplemente haciendo un cambio en el archivo readme.md (agregué algunos espacios), confirmando y presionando

+1

@tjwebb , ¿está encontrando que esto no es, de hecho, podar sus node_modules?

https://github.com/heroku/heroku-buildpack-nodejs/blob/master/bin/compile#L69

npm prune no actualiza la memoria caché, solo limpia los paquetes obsoletos. Actualicé una dependencia en mi aplicación, la implementé, pero heroku no está instalando la versión más nueva de esa dependencia, todavía está usando la anterior.

Esto es indignante y ridículo. Si especifico una versión ^0.10.0 y publico 0.10.1 , heroku se niega a actualizar a la última versión sin importar lo que haga. Ejecuté heroku restart , impulsé nuevas versiones, esperé horas a que caducara el caché, etc., nada funciona.

Hola, @tjwebb , hace un tiempo creé una rama que proporciona una forma de desactivar el almacenamiento en caché. ¿Puedes intentarlo y reportar tus hallazgos?

https://github.com/heroku/heroku-buildpack-nodejs/pull/103#issuecomment-46722251

También @tjwebb , ¿has probado esto?

https://github.com/heroku/heroku-repo#purge_cache

Estoy de acuerdo en que no debería ser necesario un comando separado de 'purgar caché'. Solo asegurándome de que ese sea el comportamiento que buscas.

La sugerencia de @hunterloftis purge_cache me solucionó algunos problemas de almacenamiento en caché.

Esto debería solucionarse con BUILD_CLEAN en https://github.com/heroku/heroku-buildpack-nodejs/tree/yoga

Solo para que conste: creo que en las versiones actuales, debe configurar NODE_MODULES_CACHE=false para limpiar el caché. Estoy usando la versión 70 de este paquete de compilación.

@philss Implementé mi aplicación angular en heroku y me enfrenté a un problema similar y no pude configurar NODE_MODULES_CACHE=false ya que usé github como medio para implementar. Cualquier otra forma en que pueda establecer node_modules_cache en falso.