Casser - pas construire. Ou la dévolution

Récemment, quelques articles intéressants ont paru sur Habré. Le premier était consacré au problème de minification ES6 , le second sur les conseils généraux d'optimisation de webpack utiles .

Tout irait bien, mais ils ont tous deux contourné le problème de la division des faisceaux en ES6 et ES5 à des fins de minification et d'autres optimisations. Et en général, alors que certains écrivent et écrivent des articles à ce sujet , d'autres (presque tous) ignorent cette technique.

Parce que depuis longtemps. Cher Et pas tellement.

Mais c'est nécessaire rapidement, à moindre coût et plus bête. Vous devriez peut-être simplement inverser l'évolution.

Idée

Décrire une «idée» n'est pas une bonne idée. Il vaut mieux décrire comment cela devrait fonctionner. Comment le processus de formation des faisceaux devrait fonctionner:

• J'ai un code
• Je le compile sous mon navigateur "développement"
• et tout fonctionne.

Le navigateur de développement est là - pour que async / wait, générateur, classes, fonctions fléchées et ainsi de suite. En général, ciblez: les esmodules dans le babel.

Je ne sais pas pour vous, mais j'aime cette idée. Voici juste les anciens navigateurs qui sont encore parmi nous, cette idée ne convient pas de cette façon. (et donc nous sifflons tous en production, en assaisonnant avec un demi-mégaoctet de polyfills)

Et c'est exactement ce qui doit être corrigé.

Dévolution

La dévolution est un petit utilitaire cli qui prend votre bundle compilé en cible: esmodules et le dégrade en es5, en ajoutant tous les polyfichiers nécessaires en cours de route.

Bref, alors:

• tous les scripts js sont
• exécuter babel avec un plugin actif (fork useBuiltins: «usage») qui définit les polyfichiers requis. C'est rapide, car il n'y a pas de transformations.
• pour chaque fichier, tous les polyphiles dont il a besoin sont collectés (moins ceux qui sont déjà dans le bundle principal), fusionnés, exécutés via terser et ajoutés en haut du fichier.
• chaque fichier sera exécuté via swc, une version rouille de babel qui supprime le code à un niveau que IE11 comprend. Fonctionne 10 à 60 fois plus vite que babel. Il ne prend pas en charge divers plugins, mais ce n'est pas nécessaire - tout ce qui est nécessaire est __ déjà__ appliqué.
• terser est à nouveau superposé au résultat, mais avec mangle désactivé (compression du nom), ce qui est encore rapide.
• Tout cela se fait chez les travailleurs.

J'ai exécuté le code sur trois projets de différents niveaux de difficulté:

• projet 1, 60 fichiers js finaux (fractionnement de code). Construisez 400s de temps. Dévolution 30s.
• projet 2, 1 fichier js final (30 Mo). Temps de construction 120s. Dévolution 10s.
• projet 3, 1 fichier js final (2 Mo). Temps de construction 20s. Dévolution 5s (au début des travailleurs, beaucoup de choses sont perdues).

Le bonus du pack ESM était un peu étrange:

• un projet a perdu 400 kb de babel / polyfill. Rien "sur" les puces de navigateur n'y était utilisé banalement, et dans "esm" elles n'ont pas besoin d'être polies
• un projet a perdu 10% en raison du code beaucoup plus compact des générateurs, des constructeurs asynchrones / attendent et des classes
• Un projet est devenu plus gros, car les transformations babel «lâches» rendent parfois le code plus compact. Mais le mode lâche est une option un peu dangereuse, tandis que le code «ES6» est «sûr».

Encore une fois:

• nous prenons le code ES6 (plus précisément esmodule, let / const sera remplacé par var pour des raisons de vitesse)
• en faire ES5
• jeter du côté des polyphiles
• disperser sur les papas, ajouter des liens symboliques vers d'autres fichiers
• nous modifions la connexion des scripts aux pages de manière un peu plus intelligente (les modules / nomodules IE11 ne comprennent pas)
• fait - ESM pour 85% des compteurs personnalisés, ES5 pour ceux du réservoir.

C'est simple. Vite. Tout simplement stupide. Nous avons mis à niveau le bundle. Anciens navigateurs! Au - servi.

Eh bien, les nouveaux navigateurs recevront un bundle avec presque pas de polyfills, sans transformations terribles de générateurs et asynchrones / attendent, avec des fonctions fléchées sans tambourins (et ils sont généralement plus rapides). En général, tout le monde est content, il semble que c'était à l'origine prévu.

github.com/thekashey/devolution

PS: En fait, pour le moment, la dévolution n'utilise pas swc , car elle rend parfois le code peu fonctionnel - github.com/swc-project/swc/issues/280 , Babel n'est pas tellement plus lent - où swc a été corrigé en 20 secondes, babel peut le faire en une minute. Avec un temps de construction «normal» - à partir de 5 ans - c'est un gros plus

PS: Si tout à coup il devenait intéressant pourquoi la dévolution - la vidéo est ici .