Oué mais tu interprète mal ce que je viens d'écrire. Son discours est de dire qu'il est mieux pour soit, pour son esprit, pour son développement de retenir la dépendance qui a un nom clair que le oneliner (dans le meilleur des cas) assez imbitable (dans la majorité des cas) qui va faire le même taff. Son exemple sur zéro positif/négatif est assez intéressant dans ce sens. De toute façon, s'il n'existerait pas en module npm tu ferais quoi, tu l'écrirais une première fois. Puis si tu dois l'utiliser à plusieurs endroits de ton code, tu en fais un helper, une fonction quelque part. Et comme c'est un helper tu commence à le sortir de ton métier. Puis de ton projet car en vrai tu l'utilises dans plusieurs. Et voilà pourquoi tu crées un module pour ça. C'est plutôt logique.
Après qu'il y ait un problème avec le JS et / ou npm est une toute autre chose (et je pense que c'est le cas, mais je ne parlais justement pas de ça).
tu peux te tenir au courant de leur activité, prévoir les mises-à-jour (par exemple, je sais que Django passe en 1.10 en août et j'ai déjà prévu les modifications pour être compatible)
Si je ne me trompe c'est quand même l'intérêt aussi de semver. Tu as prévu ton code pour fonctionner avec telle version, tu sais que si upgrade il y a et que semver est utilisé ça ne va rien cassé (parce que tu montera que sur des mineurs par exemple). Si la montée de ton framework t'intéresse (genre django, express, etc) c'est tout autre chose, c'est un élément vraiment central. Mais dans la majorité des cas ton upgrade devrait de toute façon être motivé par une vrai raison. Tes dépendances elles ne vont pas se mettre à jour automatiquement, si tu montes en version c'est que tu le veux bien au fond.
Comment peux-tu avoir la moindre garantie de qualité si tu ne maîtrises absolument rien au niveau des dépendances ?
C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.
[^] # Re: Autres exemples rigolos
Posté par CrEv (site web personnel) . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 3.
Oué mais tu interprète mal ce que je viens d'écrire. Son discours est de dire qu'il est mieux pour soit, pour son esprit, pour son développement de retenir la dépendance qui a un nom clair que le oneliner (dans le meilleur des cas) assez imbitable (dans la majorité des cas) qui va faire le même taff. Son exemple sur zéro positif/négatif est assez intéressant dans ce sens. De toute façon, s'il n'existerait pas en module npm tu ferais quoi, tu l'écrirais une première fois. Puis si tu dois l'utiliser à plusieurs endroits de ton code, tu en fais un helper, une fonction quelque part. Et comme c'est un helper tu commence à le sortir de ton métier. Puis de ton projet car en vrai tu l'utilises dans plusieurs. Et voilà pourquoi tu crées un module pour ça. C'est plutôt logique.
Après qu'il y ait un problème avec le JS et / ou npm est une toute autre chose (et je pense que c'est le cas, mais je ne parlais justement pas de ça).
Si je ne me trompe c'est quand même l'intérêt aussi de semver. Tu as prévu ton code pour fonctionner avec telle version, tu sais que si upgrade il y a et que semver est utilisé ça ne va rien cassé (parce que tu montera que sur des mineurs par exemple). Si la montée de ton framework t'intéresse (genre django, express, etc) c'est tout autre chose, c'est un élément vraiment central. Mais dans la majorité des cas ton upgrade devrait de toute façon être motivé par une vrai raison. Tes dépendances elles ne vont pas se mettre à jour automatiquement, si tu montes en version c'est que tu le veux bien au fond.
C'est pas sérieux comme argument. Sinon tu pousses le raisonnement et tu n'utilise aucune bibliothèque ou framework, aucune dépendance d'aucune sorte puisque tu ne maitrise pas la qualité de tes dépendances à moins d'aller toutes les auditer.