JSHint, a JavaScript Code Quality Tool

Testé un peu, j’ai tenté de basculer ma conf #eslint ▻https://github.com/brunob/leaflet.fullscreen/blob/master/.eslintrc vers #jshint sans succès pour l’insntant, donc je reste sur eslint...

@james perso j’ai bien aimé ►https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b c’est partial mais ça te donne des idées

– npm « va de paire » avec node
– amha tu peux oublier bower maintenant
– perso je suis passé de jshint à eslint :
▻https://github.com/shramov/leaflet-plugins/commit/526bee1f670dbceb5480e212c8c536a5cfb253ad
voici la conf minimale que j’utilise :
▻https://github.com/shramov/leaflet-plugins/blob/master/.eslintrc

▻http://eslint.org donc.

et du coup, me rappelant de l’excellent ►http://www.phptherightway.com, je tombe sur ▻http://jstherightway.org

un peu de lecture en perspective :-)

Je n’ai pas de guide (ça fait trop longtemps...) mais ceci dit j’ai remarqué que dans JavaScript Weekly (▻http://javascriptweekly.com) et Node Weekly (▻http://nodeweekly.com) il y avait souvent des liens vers des tutoriels de qualité.

Dans ta liste, je te conseillerais d’oublier bower (je n’utilise que npm, que ce soit pour du client ou du serveur), grunt et gulp (je fais tout mes build scripts aussi dans npm, avec de l’Unix et du JS ; quelques exemples simples : ▻https://github.com/scienceai/crossref/blob/master/package.json#L6), et JSHInt qui comme d’autres l’ont dit est dépassé par ESLint.

J’utilise ▻https://github.com/scienceai/eslint-config-scienceai comme config, mais c’est un compromis, à toi de voir s’il correspond.

De façon générale, JS c’est comme Unix : il y a plein de petits outils, mais il ne faut surtout pas partir sur l’impression que tu as besoin de tout connaître pour bien t’en servir. Il faut juste trouver ce dont tu as besoin pour commencer, puis progressivement améliorer les choses en rajoutant telle ou telle brique à ta boîte à outils (enfin tu vois quoi).

Si c’est pour faire du client, je te conseille de regarder rapidement du coté de la transpilation browserify+babel+uglify+watchify parce que c’est un peu touffu et abscons la première fois mais par contre une fois que ça roule ça devient difficile de revenir à une longue liste d’éléments script et à ES5.

Et pose des questions !

#bande_de_geeks :-*

Bisous aussi @suske

Merci à tous ! Vraiment :-)

Et oui je risque fort de revenir avec des questions ;)

Coté task-runners grunt est clairement en perte de vitesse. Npm scripts est une solution très élégante (plus légère et moins de dépendances), par contre pas toujours simple à mettre en place sur des gros projets. Dans ce cas, j’utilise Gulp (mais toujours en combinaison avec npm-scripts). Pour ajouter un lien aux excellents postés par les autres : ▻http://naholyr.fr/2015/11/ecrire-des-scripts-npm-multi-plateforme
Il y a aussi webpack, d’ailleurs qui est un « builder/packer » (plutôt qu’un task-runner utilisé pour faire du build... à la différence de Gulp/Grunt), capable de gérer aussi les CSS, les images, etc...

Coté « packers », je privilégie browserify et l’écosystème autour, mais il faut avouer que webpack a certains avantages (et dès que l’on fait du #React sur des projets moyens à gros, on le rencontre souvent).

Coté « data-binding », #React est plus que populaire... mais n’est pas toujours le plus simple ou le plus élégant (franchement il y a tout et n’importe quoi dans son écosystème). Pour des projets petits à moyen, j’aime beaucoup VueJS que je trouve largement sous-estimé (le technical-marketing-driven development de la communauté JS est... fatiguant :-S)

Enfin, si tu veux être un « hipster » (et avoir peut être un cran d’avance), regarde du coté de :
– Elm (un dialecte de Haskell compilant vers du JS) – surprenant de simplicité et très intéressant, bien plus propre et simple que du React+Redux (il a servi d’inspiration aux auteurs de Redux)
– Cycle.js, pour faire du « Functionnal Reactive Programming » (pas encore suffisament testé, mais les concepts sont intéressants).

►http://elm-lang.org (la version 0.17 vient juste de sortir et est encore plus simple)
▻http://cycle.js.org

Si je puis exprimer quelques légères différences d’opinion avec @0gust1... :)

Personnellement, je bosse au quotidien sur un gros projet JS et je n’ai pas rencontré de situation où les npm scripts n’étaient pas suffisants. Il est vrai qu’on n’a pas de collaborateur sous Windows, du coup la portabilité est plus simple. YMMV !

Pour WebPack, je m’en méfie comme de la peste. J’ai tenté le coup il y a six mois pour un nouveau projet, et au départ ça avait l’air génial, presque magique. Et puis j’ai voulu configurer un truc pas tout à fait comme tout le monde... catastrophe. Au moins browserify ça ne fait qu’un truc mais ça le fait bien, et quand tu veux autre chose il suffit d’aller voir ailleurs :)

C’est vrai que la qualité de l’écosystème React est inégale, mais il y a quand même des choses très bonnes (comme react-motion, ou les linters de JSX). Personnellement je ne suis pas fan de Redux, je pense qu’il y a une place à prendre. À l’usage React même c’est quand même top.

J’espère que les gars de Cycle vont nous sortir quelque chose de bien ; ils semblent avoir bien compris les problèmes de RxJS (IMHO inutilisable même si le concept est top) avec xstream. À suivre, mais bon c’est très, très hipster pour commencer :)

Je lis cela comme de la prose ésotérique. Presque je pourrais entrer en transe si j’allumais des bougies.
:D

@rastapopoulos c’est pour toi :p

http://www.commitstrip.com/wp-content/uploads/2016/05/Strip-Pepperidge-farm-650-final.jpg

Haha, ouais, c’est un peu ça. #vieux_con

J’ai la même impression que pour la cartoon. Avant tu voulais coder, tu codais. Maintenant faut investir beaucoup de temps pour comprendre l’environnement avant de comprendre comment coder.

(et puis jquery, c’est super récent hé :p ) #dhtml

@robin pas vraiment de désaccord :) c’est vrai que ces dernières années j’ai bossé dans des environnements assez hétérogènes (l’outillage devait marcher sous Win, OSX et Linux).

Pour webpack, j’ai eu exactement les mêmes sentiments...

Sinon, je m’aperçois que j’ai oublié de mettre le lien vers #vueJS : ►http://vuejs.org Pour des projets pas énormes, je trouve ça beaucoup plus rapide/efficace que React.

Désolé pour les liens de « hipster » (c’est vrai que je ne commencerais pas par là ;-) ). Je trouve Elm néanmoins très intéressant, j’ai été très surpris en essayant. Il n’est pas encore assez intégré avec les APIs des navigateurs à mon goût : poster un form « à l’ancienne » n’est pas vraiment simple, utiliser le localStorage non plus (les trucs que j’ai constaté).

Sinon, pour @rastapopoulos , @nicolasm , je ressens ça assez fort. On a beaucoup parlé de #javascript_fatigue ces derniers temps. De mon coté, j’ai eu de sacrées prises de bec avec de jeunes devs zélotes des derniers trucs à la mode, aux avis dichotomiques, ne sachant pas faire la part des choses entre le marketing des équipes techniques des GAFAM et la réalité du code, des besoins. On peut encore écrire de très bonnes choses avec jQuery si l’on organise son code avec soin. Je suis devenu un vieux con aussi, je crois.

Il y a des niveaux dans le #vieux_con :)

Perso je ne songe même plus à la #js_fatigue, juste je passe mes journées un peu à coté du torrent de trucs qui sortent, je sirote ma bière, et de temps en temps quand il y a un bon outil qui passe je l’attrape. Il fait frais, la vue est belle.