Votre avis sur la gestion des dépendances dans nodejs ?

bonjour
En copiant un project nodejs dans un autre répertoire je constate que la dépendance entre projet n'existe pas ( "parallelle") et que les modules dépendants doivent se localiser dans un sous répertoire du projet ( module) principal .

Ainsi pour donner un exemple gulp et gulp-module contiennent tous un répertoire node_modules qui contiennent le module tildify et la version est la même dans les deux package.json ; c'est à dire la 1.20 !!

En programmation on a une librairie et on appel la même librairie /version si on a besoin . N'est ce pas bizarre de se dire que si j 'ai besoin d'une bibliothèque je dois la placer dans un répertoire enfant ( avec nodejs ici dans le répertoire node_modules

Pour un projet utilisant le module browsersync je suis a 6 hiéarchies de node_modules !!!! J'espère que Microsoft Windows ne va pas bloquer nodejs car pour un simple copier/coller une alerte apparait déja !!! Pour l instant cela fonctionne .... heureusement !!



Modifié par 75lionel (11 May 2016 - 23:29)

Bonjour,

c'est ce que ne fait pas bower qui gère ses dépendances "à plat" (flat, 1 niveau de profondeur) mais cela pose d'autres problèmes que euh j'ai oublié, désolé

Concernant Windows, s'il refuse d'effacer des répertoires parce que le chemin est trop long et que tu ne te vois pas effacer 252 répertoires un par un (histoire vraie), il y a un module node.js nommé rimraf et qui lui sait effacer ce répertoire. https://github.com/isaacs/rimraf
Déjà 3 fois que je l'utilise en 1 mois, je regrette pas de l'avoir installé "globalement" avec npm install -g rimraf

Bonjour,

En fait, il y a le pour et le contre.

Le contre, c'est évidemment ce que tu évoques: des dizaines de répertoires node_modules imbriqués et beaucoup de redondance apparament inutiles.
J'ai aussi régulièrement le problème avec les chemins trop longs. IL faut dire que Windows est terriblement con, il est capable de gérer les chemins longs dépassant les 260 caractères si on les préfixe par \\?\\ (cf. MSDN), mais l'explorateur windows lui-même ne le fait pas en interne.

Cependant, le contre de l'autre façon, c'est-à-dire installer toutes les dépendances dans le même répertoire, peut poser d'autres problèmes.
Notamment, si tu utilises un package A qui lui-même utilise C, et que tu utilises aussi un autre package B qui a aussi besoin de C, il y a le risque d'un conflit de version; ce qui ne peut pas arriver avec l'approche npm car A et B peuvent charger deux versions différentes de C en parralèle.

Ce genre de conflit insoluble, ça peut être la catastrophe à gérer pour des projets Java qui utilisent maven par exemple ! Sans compter les potentiels problèmes de sécurité parce que la lib X ne peut pas être mise à jour parce que Y ne supporte que l'ancienne version abandonnée depuis 3 ans.

Bonjour Quentin,

QuentinC a écrit :
J'ai aussi régulièrement le problème avec les chemins trop longs. IL faut dire que Windows est terriblement con, il est capable de gérer les chemins longs dépassant les 260 caractères si on les préfixe par \\?\\ (cf. MSDN)

Pour résoudre un problème similaire, cela m'intéresse ce lien vers MSDN...

bonjour
il semble que toutes les versions de windows ont un problème avec MAX_LENGTH mais seulement au niveau applicatif selon le choix du développeur de l'API Windows. C'est un choix d 'implémentation de Microsoft depuis les début de DOS/windows et donc ne peut être considéré comme un bug.Microsoft c etait engagé a faire évoluer ces OS vers POSIX mais ce n 'était qu'un engagement . Ce qui est sur est que windows explorer est implémenté de façon à ne pas supporter, résoudre ce problème et qu'aucun shell microsoft ( cmd , powershell ?) n 'utilise la syntaxe UNC . Nodejs a eu dans le passé un problème avec MAX_LENGTH qui a été réglé.si nodejs utilise une librairie système dépendant s'éxecutant sur l'OS Microsoft alors il peut y avoir des problèmes . Interix etait un service POSIX dans microsoft mais a été racheté par microsoft et n'est plus proposé actuellement par Microsoft dans les dernières versions "professionnelles" de ses OS. En général les outils non microsoft ( gcc , gnu ) existe dans l'OS de Microsoft grâce à des librairies /outils unix et donc "souvent" en mode CLI ne doivent pas poser de problèmes ( voir msys) . Ce problème de MAX_LENGTH n 'est pas actuellement liè à un problème de type de formatage comme NTFS.

Si on va dans les détails plusieurs concepts interviennent dans l'écriture du path ( url local mais pas que) et du nom de fichiers en syntax 8.3 : ansi /unicode , code page , syntax unix , microsoft namespace . Il est à noté que la façon de naviguer entre les fichiers est la base à la compréhension des OS , de Dreamweaver ( CC et templates ) des CMS et du directory traversal ( wiki hacking).

Pour revenir à l'OS de Microsoft et nodejs : en gros en utilisant des path long ; la navigation est possible mais le problème se pose pour l' éxecution des fichiers natifs dll qui s'y trouvent! ( voir ici ) a. Donc si nodejs utilise des modules natifs ( compilation C pour OS et pas "javascript" V8) pour des raisons de rapidité JSON.parse, ) alors des problèmes peuvent apparaitre.

Pour venir a bout de ces problèmes plusieurs solutions
-changer d OS contre un unix like ( Mac , Linux , red hat , ubuntu )
-utiliser machine virtual vagrant, virtualbox
-utiliser que du POSIX
- use a win POSIX OS react
- outils compatible POSIX comme ( mingwin , cygwin)
-créer des liens virtuels ( junction path) mais pas fiable ( à confirmer/étudier )
-utiliser outils FARmanager semble une solution ( installé mais pas testé ) Il se peut que l' outils FARmanager est implémenté pour supporter les longs noms de répertoires/ fichiers en utilisant les possibilités de windows ou des librairies "POSIX" ( je n ai pas encore regardé le compilateur et le code source de farmanager).
-syntaxe particulière ( ici , ici ) pour accéder aux conteneurs (fichier<=> = répertoire). Mais utiliser la syntaxe \\?\ syntax entraine la perte de l utilisation des path relative paths (ici).
-faire du lobbying auprès de microsoft ! ( n'a jamais fonctionner et ne fonctionnera jamais actuellement pour ce "problème" )

sinon l'évolution des versions de nodejs , de npm et des modules montre que ce problème est pris en compte pour l OS de microsoft ( lire ce post github )
-flatten package
-npm v3 change la manière de gérer les dépendances inter module ( changelog) et apporte une solution aux limitations de windows OS
--npm2nix blog github .
-microsoft propose de changer le runtime de nodejs ( google v8) par son moteur : chakraCore
-Nodejs Tools for Visual Studio ( NTVS) 1.5 qui utilise chakra , et un explorer ( non pas l explorer windows ) appelé Visual Solution Explorer "indépendant" de l OS file system !!

mots clé nested module <=> flat module
Est ce que microsoft va aller concurrence V8 et closure compiler avec typescript ?
Modifié par 75lionel (14 May 2016 - 19:03)