Heroku-buildpack-nodejs: Nettoyage du cache

Un moyen de vider le cache serait formidable, un client aimerait également une fonction "npm update"... je ne sais pas comment nous pouvons supporter cela, mais s'il pouvait vider le cache, il pourrait au moins réinstaller son paquets.

C'est en fait un problème assez sérieux !

Par exemple, si je construis une application qui dépend uniquement d'express dans package.json, mes node_modules ressembleront à ceci :

--> exprimer
--> se connecter

Si je décide ensuite que j'ai besoin d'un accès direct pour me connecter à partir de mon application à l'occasion, je l'ajouterais à package.json, puis mes modules de nœud ressembleraient à ceci :

--> exprimer
--> se connecter
--> se connecter

Express utilise maintenant une instance de connexion différente de celle de mon application ! Cependant, si je faisais un npm rebuild localement, ou si je clonais l'application à nouveau et commençais avec un nouveau npm install , je finirais comme ça :

--> exprimer
--> se connecter

Express grimperait automatiquement dans l'arborescence pour utiliser la même instance de connect.

Normalement, il s'agit d'une différence mineure et ne sera pas un problème, mais il peut y avoir des bogues très subtils. Par exemple:

1) Express dépend, par exemple, de connect >= 1.0.1. Donc, sa copie de connect sera 1.0.1. Si je mets à niveau plus tard connect dans mon application, j'obtiendrai peut-être 1.0.2, mais express utilisera toujours 1.0.1. Ainsi, les fonctionnalités de la 1.0.2 ne seront pas disponibles via express, et il n'y a aucun moyen de la mettre à niveau !

2) Si connect stocke certaines propriétés d'instance sur lui-même, celles-ci ne seront pas disponibles aux deux endroits. Dans le cas de connect, il le fait en fait avec la collection connect.bodyParser.parsers , qui peut être mise à jour par l'utilisateur pour ajouter des analyseurs de requêtes supplémentaires en fonction du type (par exemple, en ajoutant la prise en charge des requêtes formatées 'application/lolcats').

Sans moyen de forcer une reconstruction de vos node_modules, vous resterez coincé dans ce genre d'enfer NPM, où les versions précises de vos différents modules et leur emplacement sont déterminés par votre package.json de niveau supérieur combiné à votre historique de le mettre à jour et les poussées ultérieures vers heroku. Idéalement, il serait généré de manière déterministe uniquement en fonction de l'état de package.json à un moment donné, et non en fonction d'une série introuvable de mises à jour incrémentielles.

Veuillez ajouter une option pour forcer un npm rebuild au lieu d'un simple npm install ! Merci :)

Je viens de découvrir une solution de contournement temporaire. J'ai modifié ce buildpack dans mon propre fork pour utiliser npm rebuild , plutôt que npm install . Il est possible de modifier l'URL du buildpack sur une application existante, même si je n'ai trouvé cela documenté nulle part. Ainsi, pour le faire de manière ponctuelle, vous pouvez faire pointer votre application vers ma version modifiée du buildpack, exécuter un déploiement, puis la pointer en arrière.

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

Mais il serait toujours très pratique de l'avoir en option lors du déploiement, ou peut-être via le heroku cli. Dans l'état actuel des choses, nous ne pouvons pas exécuter npm rebuild via heroku run , bien que vous puissiez exécuter node via heroku run , alors peut-être que npm doit simplement être mis à disposition là?

@bcherry Malheureusement, les modifications apportées au système de fichiers dans une session heroku run ne sont pas permanentes. npm rebuild pourrait être la meilleure solution mais entraînerait la recompilation de votre application à chaque poussée, ce qui n'est pas souhaitable non plus. Pourtant, cela pourrait être mieux que le statu quo.

J'ai utilisé la reconstruction npm via mon buildpack personnalisé, et à part le volume supplémentaire de sortie, je n'ai pas trouvé qu'il ajoutait beaucoup de temps au processus de déploiement. Ce n'est pas tout à fait la même chose que rm -rf node_modules && npm install , cela fait certainement beaucoup moins de travail.

Ah cool. rebuild fonctionne-t-il également sur une nouvelle installation ? Si c'est le cas, j'enverrais une longue demande d'extraction pour changer install en rebuild .

Vous savez, maintenant que je cherche un peu plus, il semble que j'aie quelque peu mal interprété "reconstruire". Il recompile simplement les packages qui ont besoin d'être compilés, par exemple si vous avez mis à jour node. Il n'est donc pas clair que cela résoudrait les problèmes d'arbre de dépendance. Cependant, dans la pratique, j'ai trouvé que l'utiliser sur mon application résolvait un problème de dépendance qui n'était pas avec un package compilé, donc je ne sais pas pourquoi. Mais il semble qu'il serait en fait nécessaire de faire à la fois npm install et npm rebuild , plutôt que simplement la reconstruction. Je vais l'examiner un peu plus et mettre à jour si je trouve une solution raisonnable et complète à ce problème.

La gestion de npm a été quelque peu modifiée dans les dernières versions du buildpack. Veuillez me faire savoir si vous rencontrez toujours des problèmes.

Ce n'est peut-être pas le bon endroit pour le mentionner, mais j'ai un problème très similaire avec ma buildback Python personnalisée - je pense que c'est un problème général de la plate-forme Heroku, non spécifique à un buildpack particulier. Garder le cache correct est une nécessité dans tous les buildpacks ; tout comme cela permet aux développeurs de buildpack de vider le cache (par exemple, lorsque la sémantique du cache est toujours incorrecte parce que je pirate le buildpack...).

Étant donné que cela n'est plus lié à un buildpack particulier, je ne sais pas où prendre cela. Le buildpack de Python ? Ici? Une liste de diffusion ? [email protected] (probablement la pire option, car ce n'est pas public...).

Je vois aussi ce problème. J'ajoute des dépendances à package.json, pousse, puis supprime les dépendances et pousse à nouveau. Heroku semble également installer les anciennes dépendances, ce qui semble tout simplement inutile...

J'ai un problème similaire avec un heroku-buildpack-php personnalisé pour Laravel. Je l'ai compilé après avoir réalisé que j'avais besoin d'exporter le PATH, puis une fois le script Laravel exécuté, j'ai remarqué que mon php.ini n'activait pas pdo_pgsql - j'ai donc ajouté l'extension et maintenant le buildpack ne se recompile pas?

J'ai pu vider le cache en modifiant simplement le fichier readme.md (ajouté quelques espaces), en validant et en poussant

+1

@tjwebb trouvez-vous qu'il ne s'agit pas en fait d'élaguer vos node_modules ?

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

npm prune n'actualise pas le cache, il nettoie simplement les paquets obsolètes. J'ai mis à jour une dépendance dans mon application, je l'ai déployée, mais la nouvelle version de cette dépendance n'est pas installée par heroku, elle utilise toujours l'ancienne.

C'est rageant et ridicule. Si je spécifie une version ^0.10.0 et que je publie 0.10.1 , heroku refuse de mettre à jour vers la dernière version quoi que je fasse. J'ai exécuté heroku restart , poussé de nouvelles versions, j'ai attendu des heures que le cache expire, etc., rien ne fonctionne.

Hé @tjwebb, j'ai créé une branche il y a quelque temps qui permet de désactiver la mise en cache. Peux-tu essayer et rapporter tes découvertes ?

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

Aussi @tjwebb avez-vous essayé cela?

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

Je suis d'accord qu'une commande "purge cache" distincte ne devrait pas être nécessaire. Assurez-vous simplement que c'est le comportement que vous recherchez.

@hunterloftis purge_cache tip a résolu quelques problèmes de mise en cache pour moi.

Cela devrait être corrigé par BUILD_CLEAN dans https://github.com/heroku/heroku-buildpack-nodejs/tree/yoga

Juste pour mémoire : je pense que dans les versions actuelles, vous devez définir NODE_MODULES_CACHE=false afin de nettoyer le cache. J'utilise la version 70 de ce buildpack.

@philss J'ai déployé mon application angulaire sur heroku et je suis confronté à un problème similaire et je n'ai pas pu définir NODE_MODULES_CACHE=false car j'ai utilisé github comme moyen de déploiement. Toutes les autres façons de définir node_modules_cache sur false.