Parcel, retour d'expérience

Dans ma quête de l’outil parfait pour :

Compiler les fichiers Sass
Et/ou fusionner les fichiers CSS
Minifier le résultat
Et tant qu’à faire minifier aussi les fichiers Javascript (j’ai rarement besoin de les fusionner par contre)
Et cerise sur le gâteau s’il pouvait aussi s’occuper de « packager »^[1] les modules

Ce qui est déjà un bon début, je profite du démarrage d’un projet de thème pour explorer l’état de l’art en la matière.

L’idée, une fois trouvé le bon outil, s’il existe, est d’appliquer cette procédure à la centaine de modules (thèmes et plugins) dont je m’occupe et possiblement moderniser la production des releases de Dotclear — oui je suis un doux rêveur !

J’ai listé Parcel, Webpack, Gulp, Grunt ; on m’a aussi mentionné Rollup (que je ne connais pas du tout). J’ai donc commencé hier avec Parcel.

En préambule, et parce que j’ai pas loin d’une centaine de projets, il est hors de question pour moi d’installer de tels outils, qui sont quasi sinon tous dépendants de node, de façon locale. J’ai regardé pour Parcel, ça veut dire 185Mo pour l’installation basique, multiplié par le nombre de projets on arrive à plus de 18Go, juste pour remplir la mission projetée ; c’est clairement abusé. Donc ça ne pourra être qu’une installation globale.

Donc installation globale de Parcel, d’après leur doc :

sudo npm install -g parcel@next

J’ai utilisé la commande npm ne sachant pas trop la différence avec la commande qui utilise yarn ; d’ailleurs si quelqu’un peut me dire ce qui est le mieux ?

Jusque là pas de souci.

Je déplace mon fichier CSS — qui comporte un @import d’un fichier de normalisation — dans un répertoire src/css et je lance la commande suivante :

parcel src/css/style.css

Jusque là pas de souci, j’ai un nouveau répertoire dist avec à l’intérieur ma feuille de style complète.

Je suis joueur, donc maintenant, plutôt que s’occuper d’une simple feuille de style CSS, je vais voir ce que ça donne avec du Sass. Je copie donc ma feuille de style src/css/style.css dans src/scss/style.scss sans rien changer au contenu de la feuille de style.

Normalement ça doit marcher pareil, dixit la doc qui indique que la gestion des fichiers Sass fait partie du paquet. Innocent je lance la commande :

parcel src/scss/style.scss

Et là, patatras :

ℹ️ Server running at http://localhost:1234
🚨 Build failed.
Error: Failed to install @parcel/transformer-sass: Callback must be a function. Received undefined
Error: Failed to install @parcel/transformer-sass: Callback must be a function. Received undefined
    at install (/usr/local/lib/node_modules/parcel/node_modules/@parcel/package-manager/lib/installPackage.js:171:11)
    at async PromiseQueue._runFn (/usr/local/lib/node_modules/parcel/node_modules/@parcel/utils/lib/PromiseQueue.js:108:7)
    at async PromiseQueue._next (/usr/local/lib/node_modules/parcel/node_modules/@parcel/utils/lib/PromiseQueue.js:95:5)

Avec un serveur ouvert localement sur le port 1234 et je ne sais absolument pas d’où il sort ni à quoi il sert.

Je suis retourné voir la doc au sujet des fichiers Sass et ils indiquent que : Parcel supports sass files out of the box by utilizing the @parcel/transformer-sass plugin, under the hood this plugin uses the sass npm package which is the JavaScript version of dart-sass..

À défaut d’autre piste j’essaie la commande qu’ils indiquent avec le même succès que la précédente.

Et voilà, fin du game, parce que va comprendre le pourquoi du comment, on trouve rien sur les internets qui explique comment régler ce problème !

Autant dire qu’un débutant dans le métier — ce que je suis d’une certaine façon —, s’il n’a pas sous la main un « sénior » ou un sachant capable de lui expliquer le pourquoi du comment et la « bonne » manière de se servir de Parcel, il va pas insister longtemps.

Je précise que Compass et Sass utilisés jusqu’alors pour Dotclear et quelques thèmes, fonctionnent parfaitement sur ma machine, si on excepte les quelques messages qui indiquent que ça devient obsolète.

Un compass version renvoie :

Compass 1.0.3 (Polaris)
Copyright (c) 2008-2021 Chris Eppstein
Released under the MIT License.
Compass is charityware.
Please make a tax deductable donation for a worthy cause: http://umdf.org/compass

Et un sass —version renvoie :

1.32.5 compiled with dart2js 2.10.4

Comme je n’ai pas envie de passer plus d’une journée sur chacun de ses outils, je vais donc m’occuper du suivant sur ma liste…

Note

[1] Au sens du format de package attendu par Dotclear pour l’installation d’un plugin ou d’un thème.

$ mkdir parcel-test $ cd parcel-test/ $ yarn init $ yarn add parcel $ echo "require('style.scss');" > index.js $ echo ".test { .r { color:red;} .b { color:blue; } }" > style.scss $ yarn parcel build ./src/index.js --dist-dir ./dist/ --public-url ./

7 réactions

Fil des commentaires de ce billet

1 De Biou - 26/03/2021, 19:19

Bon bah désolé de t’avoir lancé sur une mauvaise piste. Pour ton besoin je doute que tu aies besoin d’un outil en fait. Un Makefile ou un script Shell feront l’affaire.
2 De Franck - 26/03/2021, 21:28

Ne soit pas désolé, j’en ai retiré de l’expérience !
3 De Michel Loiseau - 27/03/2021, 07:04

Si je suis globalement assez largué pour tout ce qui concerne Sass et toutes ces choses, ça ne m’empêche pas d’admirer ce petit moteur Mosquito qui équipe cette fière bicyclette.
4 De ldbglobe - 29/03/2021, 21:42
Parcel n’est pas vraiment fait pour avoir du CSS comme point d’entrée (et du SASS encore moins). C’est pour cela que “out of the box” ça n’a pas fonctionné.

Pour ma part avec node 15.x et yarn 1.2 cette séquence fonctionne parfaitement
```
$ mkdir parcel-test
$ cd parcel-test/
$ yarn init
$ yarn add parcel
$ echo "require('style.scss');" > index.js
$ echo ".test { .r { color:red;} .b { color:blue; } }" > style.scss
$ yarn parcel build ./src/index.js --dist-dir ./dist/ --public-url ./
```
Si la sortie ne se fait pas dans la dossier dist il est conseillé de retirer l’entrée main: "index.js", dans le fichier package.json

Parcel fonctionne plus que bien du moment que le projet reste simple ou du moins dans les standard d’organisation d’une appli web.

Par contre il sera difficile de l’adapter pour des projets un peu plus exotique.

Webpack quand à lui bien que proposant lui aussi du “zero config” offre un degré d’adaptation très important et on peu lui faire peu ou prou n’importe qui du moment que l’on se penche un peu sur la documentation (bien plus complète que cette de parcel) et son écosystème de plugins.
5 De Franck - 29/03/2021, 21:49

Je comprends, cela dit toute la doc qu’on trouve sur le net s’appuie sur une installation locale, et donc propre à chaque projet, des modules node nécessaires. Or un de mes pré-requis est que je ne veux pas dupliquer une centaine de fois ceux-ci, d’où mon installation globale et c’est là que les problèmes commencent :-)

J’aime assez ces logiciels/outils qui permettent plusieurs types d’installation mais qui ne fonctionnent que sur le type adapté à un unique projet de type appli web.

J’ai testé Webpack aujourd’hui, j’en parlerai brièvement demain, et c’est pas beaucoup mieux.
6 De ldbglobe - 29/03/2021, 22:12
C’est le modèle de node/npm qui veux ça. Il existe tellement de version de chaque outil disponible que la gestion par projet reste largement préférable pour assurer le fonctionner à long terme.

Avec yarn 2 et leur système de Plug’n play, on élimine une partie du problème (attention toutefois au fait que ça ne supporte pas les modules déclaré au format ESM, mais jusqu’ici cela ne m’a jamais bloqué)

Le projet sur lequel je bosse actuellement (qui n’a pas beaucoup de dépendance je passe d’un dossier node_modules contenant 15Mo pour ~1600 fichiers à un dossier .yarn de 3.5Mo pour une petite centaine de fichiers ce qui est nettement mieux. Dans les deux cas, ce sont des ressources qui ne font par partie des sources de mon projet. Si quelqu’un bosse à partir du dépôt GIT à lui de lancer un yarn des familles pour installer les dépendances avant d’exécuter un des scripts déclaré dans le package.js

Ce qui est sur c’est que quel que soit l’outil utilisé, du moment que c’est node/npm qui est derrière, travailler avec des installation global c’est prendre le risque d’avoir des projets incompatibles. Et surtout cela implique l’absence total de suivi des composants nécessaire au bon fonctionnement d’un projet.
- Global = boite à outil présente sur la machine. Chacune à ce qu’il veux chez lui et dois savoir à quoi ça sert. En cas de problème de version ça peut devenir un enfer. Dans mon cas j’ai des projets exploitant webpack en version 2, 3 4 et 5 il est tout bonnement impossible de gérer tout cela via un déploiement global sur ma machine de travail
- Local (avec un package.json pour tout déclarer) = il suffit de lancer un npm install ou un yarn pour installer les dépendances prévu et avoir un environnement fonctionnel
7 De Franck - 30/03/2021, 08:25

Merci pour les détails !

Open Time