Comment travailler dans l'écosystème JS ?

J'ai repris il y'a quelques mois le dev front end après une longue période de backend et client lourd.
Quand j'ai arrêté le front , il n'y avait plus vraiment de discussion quant à la lib à utiliser en js. Jquery avait écraser tous le monde. Il restait bien quelques aventuriers originaux qui utilisaient mootols ou prototype mais l'écosystème était relativement stable. on pouvait lancer une application pour quelques années sans trop de soucis.

Aujourd'hui c'est j'ai l'impression que c'est l'enfer et qu'il devient impossible de choisir une techno pérenne.
Les framework disparaissent aussi vite qu'il arrivent et ne doivent leur salut qu'au buzz qu'il sont capable de générer.

Avec la sortie d'Angular2 (une tuerie au passage) en septembre j'ai lancer le dév d'une nouvelle appli , mais j'aurais tout aussi bien pu le faire en React , en Vue , en Inferno, en Aurelia , ... et j'en passe.
Angular2 m'a convaincu par l'utilisation de typescript et leur roadmap plutôt clair.

Mon appli est en développement , et depuis la version 2 , la team angular à sortie 18 releases et ce sans compter la v4 en beta :marteau:
Je conçois qu'il est nécessaire de faire évoluer les outils , mais je passe presque autant de temps à suivre les màj de mon framework qu'à développer. Et j'ai l'impression que c'est comme ça un peu chez tous les protagonistes.

Je travail dans un contexte industriel ou j'ai besoin d'être innovant et donc d'utiliser des nouvelles technos , mais j'ai également besoin d'assurer une pérennité forte à mes développements.

Du coup je m'interroge ,
comment travaillez vous dans cet écosystème instable ?
Comment choisissez vous vos technos pour assurer des durée de vie importante sans tout reprendre tous les ans ?
Qu'est ce qui me garantie que dans 2 ans mon npm install fonctionnera toujours ?

Bref , comment travailler de manière professionnelle ?

Je n'ai pas de réponse définitive.

Juste une chose : il faut installer tous les packages npm localement au projet, y compris TypeScript et les outils de build (uglifyjs, node-sass, webpack etc.). Ne pas utiliser du tout l'option "-g".

Pour être passé par une réflexion similaire il y a 2 mois et faisant aussi principalement du backend, je confirme que c'est l'horreur. Déjà c'est casse tête de choisir les outils de build, le framework/libs et la suite de tests, mais en plus dans 1 an la moitié de tes outils vont être obsolètes.

La seule bonne nouvelle c'est que NPM est stable du coup ton npm install devrait continuer de fonctionner, je n'imagine pas un gestionnaires de dépendance faire une purge des paquets disponibles. Les suites de tests semblent relativement stables également.

Pour le reste malheureusement la seule solution est de partir avec les outils les plus récents et suivre leurs mises a jour. A priori en ce moment l'outil de build a la mode est webpack mais webpack2 semble pointer le bout de son nez donc a voir. Pour les frameworks/libs, Angular2 a un début mitigé car la communauté d'Angular n'est pas contente de la rupture entre les 2 versions, mais c'est le framework de Google et "a priori" les versions suivantes ne devraient pas trop changer, c'est la pour rester. VueJS semble avoir le vent en poupe mais je n'ai pas testé. Nous sommes partis sur React de notre coté car personne dans l’équipe ne se sert de TypeScript et que l'environnement React semble assez stable + React Native est un plus intéressant.


Ma prédiction a 2 sous : au minimum les outils de build sont voués a changer dans un futur proche au fur et a mesure de l'adoption de HTTP/2 qui favorise l'envoi de multiples petits fichiers alors qu’actuellement on minifie tout dans un gros fichier.

Citation:

---

Envoyé par grunk

...Qu'est ce qui me garantie que dans 2 ans mon npm install fonctionnera toujours ?

Bref , comment travailler de manière professionnelle ?

---

Tu installe un serveur Sonatype Nexus chez toi et tu lui ajoute le support des repo npm php et autre que tu configure en proxy
premier avantage tes développeur n'ont plus besoin d'internet pour charger les packages
deuxième avantage dès qu'un développeur l'a téléchargé il est disponible en local pour les autres
troisième avantage tu peux déplacer le contenu du cache vers un repos local (prioritaire) si le package disparaît d'internet tu l'a toujours chez toi.
A+JYT

Citation:

---

Qu'est ce qui me garantie que dans 2 ans mon npm install fonctionnera toujours ?

---

Citation:

---

La seule bonne nouvelle c'est que NPM est stable du coup ton npm install devrait continuer de fonctionner, je n'imagine pas un gestionnaires de dépendance faire une purge des paquets disponibles.

---

Effectivement on n'imagine pas npm faire une purge des paquets disponibles. Mais de par son fonctionnement, si on ne fait pas attention, pas besoin de purge pour que le npm install fasse n'importe quoi.
En effet je souhaite installer la bibliothèque lodash avec npm, je peux indiquer dans le package.json la version ">=4" de lodash. Aujourd'hui la version qui sera installée sera la version 4, mais dans quelques mois, ce sera la 5, et dans quelques années la 10. Que faire si la version 10 n'est plus compatible avec mon code ? Si j'ai noté ">=4" dans le package.json, dans 3 ans quand je ferais npm install, npm m'installera la version 10, alors que je n'ai pas tester la version 10.

Pour répondre à cette problématique, on se base sur le versionning semver, et on indique la version ^4.1.2 dans le package.json, ce qui veut dire toutes les versions 4.x.x mais au minimum la version 4.1.2. C'est déjà mieux. Mais le hic, c'est que pas tous les packages utilise le semver, on est maitre des bibliothèques qu'on inclue, mais on n'est pas maitre des bibliothèques qui sont incluent par nos bibliothèques inclues (et ainsi de suite).

Pour répondre à cette problématique, un outil a été créer. Il s'appel Yarn. Son utilisation ressemble largement à npm, et il se base sur les mêmes repositories. Mais à chaque fois qu'on fait un yarn install, ou un yarn update, l'utilitaire va creer un fichier yarn.lock, qui indique toutes les versions précises qui ont été installés. Donc dans 10 ans, quand je vais re-faire yarn install, l'utilitaire se basera sur le fichier yarn.lock, et installera les mêmes version que lors de mon dernier yarn install d'il y a 10 ans.

En plus de cela, je conseil aussi de faire des archives des node_modules, cela aide, au cas ou un package est supprimé de npm (ou que son repo git est supprimé etc...) etc...
Même si ça ne règle pas tous les problèmes, car les node_modules dépendent de la plateforme (sur windows ou linux, certaines bibliothèques installées dans le node_module ne sont pas les mêmes, car il y a des bibliothèques codées en C ou C++).

En résumé: Il faut utiliser yarn, et il faut faire des archives du répertoire node_modules.