En tant que développeurs, nous passons d’innombrables heures assis face à notre ordinateur. C’est pourquoi il est primordial de bien s’équiper pour avoir une bonne productivité. De l’écran à l’IDE, j’ai pensé qu’il pouvait être intéressant de partager mes outils de travail.

Les écrans

Quand je parle d’écrans, ce n’est pas tant la marque ou la technologie de dalle qui importe – nous ne sommes pas designers – mais plutôt le nombre. En effet, comme nombre d’entre vous, mon unité centrale se résume à un laptop. Un Macbook Pro 15’’ en l’occurrence.

C’est amplement suffisant en terme de puissance, ça offre une bonne autonomie, l’écran de 15’’ permet de se débrouiller en mobilité, mais un seul petit écran est à mon humble avis suboptimal pour prétendre à une productivité honnête.

On a beau lutter contre le multitasking car notre cerveau n’est pas fait pour cela [en], nous jonglons quotidiennement entre une incroyable quantité de logiciels. Il est bien plus pratique de tout avoir sous les yeux à la fois, plutôt que de constamment naviguer entre différents bureaux virtuels.

L’écran du milieu alterne entre le navigateur et mon éditeur de code selon les projets en cours, tandis que l’écran de droite est principalement utilisé pour l’éditeur de code. J’ai également le ou les designs en split view quand je fais de l’intégration.

Partie software

Concentrons-nous maintenant sur les outils que nous utilisons au quotidien. En tant que développeur web, commençons par le navigateur.

Je l’ai déjà mentionné, j’utilise Firefox, la Developer Edition pour être précis. Je n’ai qu’un seul plugin plugin : VueJS devtools. En outre, je trouve le thème sombre très sympa, il s’assortit parfaitement avec les autres outils de dev au design souvent sombre aussi.

Éditeur de code

En 2020, je suis passé de Atom à VSCode, ou plus exactement, VSCodium, la version libre de VSCode. J’ai migré car VSCode est beaucoup plus performant et incroyablement bien documenté.

Par ailleurs, VSCode nécessite peu de configuration et de plugins tiers comparé à Atom. Voici la liste des plugins que j’utilisais dans Atom :

• color-picker permet de choisir des couleurs à la pipette depuis différents endroits et d’appliquer le code couleurs directement dans Atom.
• emmet permet fourni une auto-complétion aux hormones. Il permet en effet d’accélérer la saisie du code html en ne tapant que les sélecteurs CSS. Ainsi, section.container.product sera transformé après appuis sur tab en <section class="container product"></section>. Sacrée économie de frappes clavier !
• file-icons ce petit outil permet simplement d’égayer votre interface en affichant des icônes spécifiques au différents types de fichiers dans les onglets et la treeview.
• git-time-machine permet de visualiser l’ensemble des commits du fichier courant sur une timeline et de comparer le fichier actuel à un commit en particulier.
• linter, comme son nom l’indique permet de linter les fichiers (automatiquement afficher les erreurs de syntaxe). Celui-ci est le linter de base, auquel viennent s’ajouter des linters spécialisés.
• linter-eslint le linter phare du JavaScript. Associé à un fichier de config et/ou des presets, il supporte évidemment l’ES5 et 6+. Nous reviendrons sur sa configuration un peu plus tard.
• linter-htmlhint vous l’aurez deviné, il permet de linter le HTML. Il possède également un fichier de conf sur lequel nous reviendrons.
• linter-stylelint, c’est le linter par excellence pour le CSS. Il s’utilise aussi avec les préprocesseurs. Il y a là aussi un fichier de conf, nous verrons cela dans la partie suivante.
• linter-less celui-ci permet de linter les fichiers Less. Oui, j’utilise Less. Simplement car c’est le premier que j’ai appris et qu’il me convient. Mais ne vous formalisez pas, il existe forcément un linter pour le Sass et pour Stylus. Ce linter valide simplement des détails spécifique à Less (tel que le fait que les variables sont déclarées etc). Par conséquent, il est à utiliser en complément de linter-stylelint.
• linter-php, on se passe de description ici. Il n’y a pas de fichier de conf.
• merge-conflicts est un résolveur visuel de conflit de merge. Ça permet de venir à bout des conflits rapidement et directement depuis l’éditeur.
• pigments surligne les codes couleurs avec la couleur décrite pas le code. Il est compatible avec Less, Sass et Stylus.

Certains plugins natifs apportent des fonctionalités comme la coloration syntaxique et l’autocomplétion. Il n’est pas inutile de jeter un œil aux snippets d’autocomplétion ainsi que leurs préfixes respectifs. Par exemple, voici ce à quoi vous aurez droit pour le JS.

Les linters

Les linters qui supportent des options permettent en général de les configurer de manière globale ou par projet. La configuration par projet apporte une plus grande flexibilité et présente l’avantage de pouvoir être commité avec ce dernier.

Ainsi, chaque contributeur possède les mêmes préférences. Les préférences locales s’écrivent dans des fichiers de config à la racine du projet. Ces fichiers s’appellent respectivement :

• .htmlhintrc
• .stylelintrc
• .eslintrc

Il faudra également, pour la plupart des linters, installer quelques paquets via Node.js. Nous y reviendrons dans la partie suivante.

L’importance des linters est grande. Ils permettent à la fois d’assurer un style de code homogène et de détecter les erreurs syntaxiques.

Une grosse partie de la config de ces derniers repose en effet sur la partie stylistique. En effet, concernant la partie validité syntaxique du code, il n’y a pas à tergiverser. Soit le code est valide, soit il ne l’est pas !

Linter le HTML

Commençons par le plus facile de tous, htmlhint. Le fichier de conf se génère via le site du projet. Il n’y a pas énormément d’options. Voici le fichier tel qu’il est chez moi.

{
    "doctype-first": false,
    "tagname-lowercase": true,
    "attr-lowercase": true,
    "attr-value-double-quotes": true,
    "tag-pair": true,
    "spec-char-escape": true,
    "id-unique": true,
    "src-not-empty": true,
    "attr-no-duplication": true,
    "title-require": true
}

Mis à part doctype-first que je mets à false car il arrive souvent d’éditer des morceaux de templates qui seront insérés et n’ont donc pas de doctype, le reste se passe d’explications.

Linter les styles

Ça se complique un peu avec stylelint. Comme il y a de très nombreuses règles, on part sur une configuration standard et on affine selon ses goûts au fur et à mesure.

{
    "extends": "stylelint-config-standard",
    "plugins": [
        "stylelint-high-performance-animation",
        "stylelint-no-unsupported-browser-features",
        "stylelint-order"
    ],
    "rules": {
        "declaration-empty-line-before": null,
        "indentation": 4,
        "number-leading-zero": "never",
        "plugin/no-low-performance-animation-properties": [true, { ignore: "paint-properties", "severity": "warning" }],
        "plugin/no-unsupported-browser-features": [true, {
            "browsers": ["> 1%", "not OperaMini all"],
            "severity": "warning"
        }],
        "selector-list-comma-newline-after": "always-multi-line",
        "order/properties-order": [
            "position",
            "top",
            "right",
            "bottom",
            "left",
            "z-index",
            "display",
            …
        ]
    }
}

Vous avez peut-être noté l’utilisation de plusieurs plugins. Le premier, stylelint-high-performance-animation, permet de vous avertir lorsque vous utiliser des animations peu performantes. Je l’ai tout de même configuré pour ne pas m’avertir lors de l’animation de paint (opacity, background…) car ce n’est pas autant pénalisant que l’animation du propriété qui déclenche le layout comme width ou margin.

Le second plugin, stylelint-no-unsupported-browser-features, avertit lors de l’utilisation de propriétés non supportées par les navigateurs ciblés. Ici, je cible les navigateurs représentant plus de 1% d’utilisateurs en excluant Opéra Mini (lequel ne supporte aucune animation donc génère trop de warning).

Le dernier plugin, stylelint-order, permet de forcer l’organisation du CSS selon un ordre précis des propriétés. Certains préfèrent une organisation par ordre alphabétique, pour ma part, je préfère avoir mes propriétés organisées selon une logique fonctionnelle.

Ainsi, les propriétés CSS appartenant à un même groupe logique (ex. positionnement, bordures etc) se trouvent groupées. C’est plus ergonomique à l’écriture et à la maintenance et surtout, comme l’ordre et la répétition se compressent bien (Huffman inside), ça se compresse mieux !

J’avais regardé du côté des configurations prédéfinies de CSScomb pour organiser les propriétés. Libre à vous de faire votre sauce maison.

Linter le JavaScript

Abordons en dernier lieu la configuration d’eslint. Il n’y a pas de configuration par défaut officielle. Je pars donc sur la configuration de AirBnB qui repose sur leur style guide. De manière similaire à ce que je fais avec stylelint, je modifie ensuite la config pour l’adapter à mon style propre.

Je vous présente ma config sans autre forme de procès, ces préférences étant majoritairement des questions de goûts, inutile d’entrer dans les détails. Les commentaires sont toujours ouverts au besoin !

{
    "extends": "airbnb-base",
    "env": {
        "browser": true, // selon qu'on soit en front ou back
        "node": true, // selon qu'on soit en front ou back
    },
    "engines": {
        "node": ">=10" // si nodejs, je précise la version minimale supportée
    },
    "globals": {},
    "rules": {
        "brace-style": ["error", "stroustrup"],
        "comma-dangle": ["error", "never"],
        "func-names": ["error", "never"],
        "import/no-extraneous-dependencies": ["error", { "devDependencies": true, "optionalDependencies": false, "peerDependencies": false }],
        "indent": ["error", 4, { "MemberExpression": 0 }],
        "max-len": ["off", 120],
        "no-continue": "off",
        "no-new": "off",
        "no-param-reassign": ["error", { "props": false }],
        "no-plusplus": "off",
        "no-underscore-dangle": "off"
    }
}

Dans un second article, je vous présenterai comment tirer parti de NPM, le gestionnaire de paquets de JavaScript afin qu’il remplisse tout à la fois les rôles de gestionnaire de dépendances et de task manager. Nous n’aurons ainsi plus à installer et configurer 50 outils différents : one tool to rule them all!