Dans cette vidéo je vous propose de découvrir Snowpack. Un outil qui se veut être une alternative aux bundler pour travailler sur des projets JavaScript.
tldnr : L'idée est intéressante mais certains points de frictiions me font lui préférer vite actuellement.
Le problème
Aujourd'hui lorsque l'on travaille sur un projet front-end on a recours à un bundler pendant la phase de développement et de production. Cependant, l'approche utilisée par les bundlers s'avère peu efficace pour le développement car il doit reconstruire un gros fichier à chaque modification (ce qui peut prendre un temps assez important sur des gros projets).
L'approche snowpack
Les navigateurs supportent aujourd'hui les modules EcmaScript ce qui permet d'envisager un futur sans bundler mais il faut toutefois régler plusieurs problèmes :
- On veut pouvoir installer des modules qui proviennent de npm.
- Certains framework imposent l'utilisation de language alternatif (vue, jsx, svelte...).
- On importe parfois du code qui n'est pas du JavaScript (.scss, .svg...).
C'est là que snowpack intervient en proposant une solution pour ces différents problèmes pour offir une meilleur expérience de développement.
Comment ça marche ?
Tout d'abord, parlons du cas npm. Lorsque vous aller installer une dépendance qui provient de npm, snowpack va installer une version ES du paquet qui pourra ensuite être utilisé par le navigateur directement (C'est d'ailleurs la même approche que celle utilisé par skypack).
Ensuite, lorsque vous importez un fichier qui n'utilise pas du JavaScript, snowpack effectuera une transformation pour le convertir en quelquechose qui sera utilisable par le navigateur.
Par exemple
import Demo from './Demo.jsx'
import './style.scss'deviendra
import Demo from './Demo.js'
import './style.scss.proxy.js'Pendant la phase de développement snowpack ajoutera aussi des scripts supplémentaires afin de mettre en place le HMR pour que vous puissiez voir vos changements en live.
La configuration de snowpack se fait au travers d'un fichier snowpack.config.js auquel on pourra ajouter des plugins pour gérer différents types de fichiers.
// snowpack.config.json
"plugins": ["@snowpack/plugin-typescript"]Et le build ?
Lorsque vous allez construire votre projet snowpack ne va pas générer une version "bundlé" de vos sources mais va générer les différents modules JavaScripts qui pourront être utilisables par les navigateurs.
Limitations
Même si l'approche "no bundle" est intéréssante elle n'est pas encore viable en production car elle crée un problème de cascade :
- Le navigateur charge le fichier index.js, le parse et identifie les dépendances
- Les dépendances sont à leur tour chargées, parsées et les dépendances sont identifiées et chargées.
- ainsi de suite jusqu'au chargement complet de tout l'arbre de dépendance.
Dans la phase de développement ces va-et-vient ne sont pas forcément génant mais cela devient problématique en production avec la latence réseau. Aussi il est toujours intéréssant aujourd'hui de bundler les fichiers pour ne générer qu'un fichier en sortie. On se retrouvera alors à devoir configurer un bundler après le passage de snowpack, ce qui n'est pas forcément super pratique (surtout pour le chargement du CSS par exemple).
Ensuite le second problème que l'on rencontre est l'utilisation des modules npm qui ne pourront pas être utilisés pour des inclusions en profondeur. Par exemple il n'est pas possible d'avoir un import qui ressemble à ça.
import Demo from 'module-lol/src/demo'Car lors de l'installation de ce module snowpack va créer une version ES6 du module et c'est tout ce qui sera exposé à votre application.
Pour conclure
L'approche de snowpack est intéréssante mais l'écosystème n'est pas forcément totalement adapté à cette approche. Le développement des modules ES6 au sein de l'écosystème npm devrait améliorer les choses dans le futur. En attendant il faudra continuer à subir les bundler ou chercher des alternatives comme vite.
