Remplace Webpack par ViteJS #1861
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
🚀 La branche est déployée !
|
mquandalle
force-pushed
the
vitejs
branch
12 times, most recently
from
e6f45fa to
68e7797
Compare
|
C'est impressionnant comment ça va vite 🐎 |
|
Après l'avoir testé, je pense que ça vaut le coup de finaliser la migration vers ViteJS :
Dans le commit précédent j'ai migré nos scripts vers ES Modules, je l'ai fait un peu comme ça pour voir mais ce n'était pas requis pour ViteJS. Ceci dit ça simplifie l'appropriation de la base de code pour un nouveau venu si tous les fichiers utilisent le même type d'import/export. Par ailleurs si on veut importer un fichier ES Module de l'appli (comme Pour le reste de la migration, confer TODO du message inital. |
mquandalle
force-pushed
the
vitejs
branch
5 times, most recently
from
fd7996e to
3528c8d
Compare
mquandalle
force-pushed
the
vitejs
branch
5 times, most recently
from
34ff771 to
191ec56
Compare
This was
linked to
issues
Dec 27, 2021
Closed
Closed
Avec vite, on n'utilise plus `process.env` côté client, mais `import.meta.env`. Par ailleurs seules les variables d'environnement préfixées par `VITE_` sont exposées au client, les autres sont uniquement disponibles côté serveur.
Réactive 2 suites de tests qui n'étaient plus fonctionnelles : - les "exemples" définis directements dans le publicodes - le StackedBarChart Suppression de mocha, mochapack, sinon, chai
Nous utilisions Jest uniquement pour les tests de non regressions qui recquièrent le “snapshot testing”. Cette fonctionnalité étant supoprtée par Vitest, il n'est plus utile de maintenir 2 environnement de tests séparés.
- Création d'un plugin personnalisé pour gérer le serveur dev et le build Rollup - Restauration d'un template.html (ne fonctionne pas encore au build) - Suppression de la config Babel
La version utilisée de react-markdown n'était pas compatible avec ViteJS. J'ai tenté la mise à jour vers la v7 qui est publiée sous forme de ES Module, ce qui nécessitait d'intégrer plusieurs changements d'API. En m'y attelant j'ai réalisé que la motivation première de react-markdown était de ne surtout pas utiliser `dangerouslySetInnerHTML`, ce qui est utile pour les cas d'usages où le markdown n'est pas digne de confiance (message d'utilisateurs par exemple). Cette contrainte oblige à alourdir sensiblement la quantité de JavaScript à charger et à évaluer. Anisi dans certains markdown que l'on affiche, on utilise la balise HTML `<sup>`, qui n'est pas parsée nativement pas react-markdown. Comme on ne peut pas faire de `dangerouslySetInnerHTML` il faut intégrer un parseur HTML complet qui rajout 60kb, juste pour quelques occurences de `<sup>` dans les pages nouveautés. Dans notre cas d'usage reparser tout le html en Javascript, n'est pas utile. markdown-to-jsx semble plus adapté et beaucoup plus léger. Par ailleurs le paquet est 5 fois plus utilisé que react-markdown : https://www.npmtrends.com/react-markdown-vs-markdown-to-jsx
Désormais nous utilisons un script NodeJS natif pour générer le code HTML pour le pré-rendu des pages. Cela est plus rapide et plus fiable que la méthode précédente qui consistait un instrumentaliser un navigateur (pupetter) https://github.com/chrisvfritz/prerender-spa-plugin Cela implique toutefois de faire attention à ne plus utiliser des variables gloables du navigateur, comme `window`, `document` ou `location` dans nos scripts. C'est plutôt une bonne pratique, mais il faudrait sans doute configurer du typage pour détecter ces usages le plus tôt possible et éviter de créer des erreurs inopinées avec le SSR.
🔥 Suppression de la dépendence "enzyme"
mquandalle
force-pushed
the
vitejs
branch
3 times, most recently
from
0dc45b4 to
dfa7e73
Compare
- Creation d'un composnant <BrowserOnly /> pour éviter le CLS - Restaure l'animation de chargement et le message de navigateur obsolète - Correction d'une chaîne de caractère dans l'UI avec des tabulations - Répare la section nouveautés - Suppression du rehooks/local-storage - Suppression de swr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TODO :
Contributing.md@react-pdf/renderernécessite des “shims” pour que les librairies NodeJS comme “buffer” ou “zlib” puisse être utilisées dans le navigateur. Cela nécessite une configuration du bundler qui était automatique avec Webpack 4, et qui est possible avec Webpack 5 ou Rollup (utilisé pour le build par ViteJS). En revanche vu qu'en mode développement ViteJs utilise les ESModule directement dans le navigateur quasiment sans transformation, il n'est pas évident du tout de porter cette configuration.Impossible to use this package with ViteJS diegomura/react-pdf#1669
smarttag.jsdans le bundle SSRConditionnal import for SSR vitejs/vite#6377
.defaultafter build while it's not required in dev (CJS dependency) vitejs/vite#2139Build an external script along with the main app vitejs/vite#6411
Prochaines étapes :
Comme indiqué dans #1491 (comment), j'évalue la facilité et l'intérêt d'utiliser ViteJS comme alternative à la seule mise à jour vers Webpack 5.
L'intérêt principal que je vois est d'améliorer sensiblement l'expérience de développement grâce à des hot-reload quasi instantanés 1. Par ailleurs, repasser sur l'ensemble de notre configuration de build peut aussi permettre de la simplifier, l’écosystème JavaScript ayant beaucoup évolué ces dernières années et plutôt dans la direction d'une standardisation des pratiques.
Les commandes
yarn start, etyarn buildfonctionnent en local, c'est encourageant car ça n'a pas demandé beaucoup d'effort !Footnotes
Pour le fun on peut même activer l'auto-save dans VSCode, en mettant une fréquence élevé ~50ms, et avoir un rendu en temps réel de l'application à chaque caractère pressé
↩