Un bundler JavaScript développé au fil de la pensée (transpileur et compilateur TypeScript natif en Zig)
(github.com/ohah)Comment faut-il étudier à l’ère de l’IA ?
Je n’arrivais pas à comprendre clairement quelle expertise était demandée, ni quelles compétences avaient le plus de valeur aujourd’hui.
J’ai l’impression que les entreprises qui embauchent des développeurs comme les développeurs eux-mêmes ne connaissent pas non plus de critères très clairs,
Mais quoi qu’il en soit, je me suis dit que rester immobile était forcément une perte.
Je me suis donc dit qu’il fallait au moins fabriquer quelque chose,
et au départ j’ai commencé simplement par créer des Chrome Remote DevTools pour apprendre.
Puis, en avançant, je me suis dit qu’il fallait aussi faire en sorte que React Native soit pris en charge avec un débogueur distant.
-> Je ne connais pas Metro, c’est trop déroutant.
-> Essayons de l’étudier en refaisant Metro en clone coding.
-> Est-ce qu’on ne pourrait pas créer pour React Native un meilleur bundler que Metro ?
-> En bricolant avec RollDown, swc et Bun, j’ai essayé de construire un bundler meilleur que Metro.
Bun et RollDown semblaient offrir le plus de potentiel, mais j’ai senti les limites dès qu’il fallait personnaliser fortement le cœur ou partir sur un fork.
Et en plus, il n’existe pas vraiment de bundler web parfaitement compatible avec Metro : il y a Flow, la syntaxe JavaScript autorisée par le moteur Hermes, et, contrairement au web classique, l’ordre d’appel qui est important, etc.
Ah… au fond, puisque c’était pour apprendre, autant créer aussi le bundler et essayer de remplacer Metro dans React Native.
Ce que je me suis dit en développant le bundler :
Alors, il suffit aussi de prendre en charge le web, non ?
Ajoutons aussi ES5, que RollDown a laissé tomber.
Puisqu’il faut exécuter RN, prenons aussi en charge le parseur Flow.
Prenons aussi en charge wasm.
Et essayons d’être plus rapides que Bun et RollDown.
Ajoutons aussi notre propre HMR.
Essayons aussi un tree-shaking plus agressif.
Et faisons en sorte que la minification soit meilleure que celle des autres bundlers.
J’ai développé le projet avec l’idée de battre, au moins dans les benchmarks et sur les fonctionnalités dont j’avais connaissance, tous les bundlers existants.
Bien sûr, je pense aussi perdre sur beaucoup de points.
Comparé aux autres bundlers, il y a naturellement encore beaucoup de choses inachevées : la stabilité, les fonctionnalités, l’écosystème et la communauté pris en charge ; même pour le tree-shaking et la minification mentionnés plus haut, certains modules sont meilleurs, d’autres moins bons.
Cela dit, les tests d’exécution ont montré que le projet surpasse déjà d’autres solutions sur certains points, et même s’il reste encore beaucoup à faire (SSL, MCP, CLI, stabilisation, documentation de l’API, etc.), j’ai confirmé que l’objectif initial — construire et exécuter des applications React Native — fonctionne correctement : après vérification sur 3 applications commerciales en build de release, build de développement et serveur de développement, tout tournait sans problème. Je me suis donc dit que je pouvais le publier à ce stade et continuer à le développer ensuite, d’où ce message.
Cela dit, le développement lui-même et les fonctionnalités de bundling (zntc est aussi compilé et distribué avec zntc) fonctionnent plutôt bien dans l’ensemble,
et les fonctionnalités essentielles comme les décorateurs, ainsi que des éléments quasi indispensables dans React Native comme worklet, TypeScript, Flow, etc., ont bien fonctionné sur les bibliothèques que j’ai testées.
Il fournit aussi des plugins pour vite et rspack, propose également un environnement de développement comme vite et rspack (RN, Web), dispose d’une documentation, d’un HMR React, prend en charge la module federation, etc.
Je pense donc qu’il possède malgré tout les fonctionnalités de base d’un bundler / transpileur, et je souhaite le publier pour recueillir des retours tout en continuant le développement.
Je n’ai écrit aucune ligne de code à la main : tout a été développé à travers des discussions intenses avec l’IA.
J’ai l’impression d’avoir poussé l’IA plus loin que pour n’importe quel autre développement de produit.
J’utilisais uniquement Claude au début, puis plus tard aussi Codex.
La période de développement du bundler en lui-même a été d’environ 3 mois (environ 3000 PR) ; si j’inclus tout le cheminement décrit plus haut, cela représente environ 6 mois de travail jour et nuit.
J’ai travaillé sans m’arrêter, en semaine comme les jours de repos, et à cause d’un certain complexe né des comparaisons inutiles avec d’autres bundlers,
j’ai aussi écrit énormément de cas de test, au point que cela en devenait excessif, afin de faire passer divers jeux de tests comme test262 à 100 %.
Tous les retours sont les bienvenus (__)
5 commentaires
Comme alternative à Metro, il y a aussi Re.Pack, qui utilise RSPack ou WebPack.
J’ai oublié de le préciser en écrivant un peu sans structure.
Comme vous l’avez dit, je me suis aussi beaucoup inspiré de Re.pack.
À ma connaissance, Re.pack et Rspack sont tous deux basés sur swc, donc ils ne prennent pas nativement en charge Flow,
et dans le cas de Re.pack, je crois qu’à partir de la version 5 il repose sur Rspack ; de la même manière, Re.pack utilise aussi swc+babel, donc je crois que des plugins très populaires comme Flow, Reanimated et NativeWind (prise en charge prévue pour zntc) sont encore transpillés avec Babel.
Personnellement, je voulais m’éloigner de Babel, donc dans le cas de zntc j’en ai fait une option prise en charge nativement par défaut.
Zntc prend aussi en charge la compatibilité avec Babel, mais je voulais si possible ramener la dépendance à Babel à zéro.
Ce sont des codes très stables et éprouvés, mais à cause des limites de JS, la vitesse reste toujours un goulet d’étranglement.
En réalité, pendant le développement, j’ai continué à comparer les benchmarks avec d’autres bundlers, et comme je l’ai constamment ressenti à l’œil nu, il est naturel qu’il soit encore en retrait par rapport aux autres bundlers en termes de fonctionnalités, de stabilité et d’extensibilité, donc je compte continuer à améliorer cet aspect.
Cela dit, comme la compatibilité du parseur avec les principales bibliothèques React Native est intégrée nativement, je pense qu’il est en avance sur les zones de goulet d’étranglement structurel qui se produisent inévitablement avec Re.pack !
Ce ne sera probablement pas un projet facile, mais je vous soutiens.
Merci !!
Hum… test262 à 100 %… En voyant juste le badge, j’ai cru que c’était du niveau de V8 haha