Un ensemble de plugins Babel qui permettent d'injecter différents polyfills avec différentes stratégies dans votre code compilé. De plus, ce référentiel contient un package qui aide à créer des fournisseurs pour d'autres polyfills.
Ce référentiel implémente ce qui a été initialement proposé sur babel/babel#10008.
Si vous recherchez des exemples de configuration rapide ou si vous souhaitez simplement voir comment migrer votre configuration, veuillez consulter
docs/migration.md.
Les principaux packages Babel ne transforment que la syntaxe JavaScript : vous devez également charger un polyfill, pour faire fonctionner les fonctions natives ( Array.prototype.flat ) ou les objets intégrés ( Reflect ) dans les anciens navigateurs.
Le moyen le plus simple de le faire est de charger directement le polyfill à l'aide d'une balise "> < script src =" https://unpkg.com/[email protected]/minified.js " > script >
Cependant, cette approche simple peut potentiellement inclure beaucoup de code inutile. Les plugins Babel implémentés dans ce dépôt injectent automatiquement les polyfills dans votre code, tout en essayant de ne charger que ce qui est réellement nécessaire. Il le fait en fonction de vos cibles de compilation et de ce que vous utilisez dans votre code.
Ces plugins (nous les appelons « fournisseurs polyfill ») prennent en charge différentes méthodes d'injection, pour mieux répondre à vos besoins.
Par exemple, si vous souhaitez injecter des importations dans les polyfills es-shims en ajoutant les fonctions manquantes aux objets globaux, vous pouvez configurer Babel comme tel :
| Configuration | Code d'entrée | Code de sortie |
|---|---|---|
{
"targets" : { "firefox" : 65 },
"plugins" : [
[ " polyfill-es-shims " , {
"method" : " usage-global "
}]
]
}
| Promise . allSettled ( [
p1 ,
p2
] ) . finally ( ( ) => {
console . log ( "Done!" ) ;
} ) ; | {
console.log("Done!");
});"> import "promise.prototype.finally/auto" ; import "promise.allsettled/auto" ; Promise . allSettled ( [ p1 , p2 ] ) . finally ( ( ) => { console . log ( "Done!" ) ; } ) ; |
Si vous souhaitez voir plus d'exemples de configuration, vous pouvez consulter les documents de migration : docs/migration.md .
Si vous souhaitez en savoir plus sur toutes les options prises en charge par ces plugins, vous pouvez consulter la documentation d'utilisation : docs/usage.md .
| Polyremplissage | Plugin | Méthodes |
|---|---|---|
core-js@2 | babel-plugin-polyfill-corejs2 | entry-global , usage-global et usage-pure |
core-js@3 | babel-plugin-polyfill-corejs3 | entry-global , usage-global et usage-pure |
es-shims | babel-plugin-polyfill-es-shims | usage-global et usage-pure |
regenerator-runtime | babel-plugin-polyfill-regenerator | entry-global , usage-global et usage-pure |
Nous maintenons la prise en charge de
core-jsetes-shims, mais nous vous encourageons à implémenter un fournisseur pour votre propre polyfill, ou pour votre préféré ! L'un de nos objectifs est d'encourager la concurrence entre les différents polyfills, afin de mieux équilibrer les différents compromis tels que la conformité aux spécifications et la taille du code.Si vous souhaitez implémenter la prise en charge d'un polyfill personnalisé, vous pouvez utiliser
@babel/helper-define-polyfill-provider. (docs/polyfill-provider.md.)
Les plugins Polyfill peuvent exposer trois méthodes d'injection différentes : entry-global , usage-global et usage-pure . Notez que les plugins polyfill n'ajoutent pas automatiquement le(s) package(s) nécessaire(s) à vos dépendances, vous devez donc les lister explicitement dans votre package.json .
Tous les exemples supposent que vous ciblez Chrome 62.
La méthode entry-global remplace une simple importation unique dans l'ensemble du polyfill par des importations vers les fonctionnalités spécifiques non prises en charge par les environnements cibles. C'est particulièrement utile lorsque vous voulez être sûr que toutes les fonctions non prises en charge sont disponibles, quel que soit ce que vous utilisez dans le code que vous compilez avec Babel. Vous souhaiterez peut-être utiliser cette méthode si :
| Code d'entrée | Code de sortie |
|---|---|
import "core-js" ; | import "core-js/modules/es7.array.flat-map.js" ;
import "core-js/modules/es6.array.sort.js" ;
import "core-js/modules/es7.promise.finally.js" ;
import "core-js/modules/es7.symbol.async-iterator.js" ;
import "core-js/modules/es7.string.trim-left.js" ;
import "core-js/modules/es7.string.trim-right.js" ;
import "core-js/modules/web.timers.js" ;
import "core-js/modules/web.immediate.js" ;
import "core-js/modules/web.dom.iterable.js" ; |
La méthode usage-global injecte des importations dans les polyfills attachés à la portée globale, mais uniquement pour les fonctionnalités non prises en charge qui sont utilisées dans votre code. Vous souhaiterez peut-être utiliser cette méthode si :
| Code d'entrée | Code de sortie |
|---|---|
foo . flatMap ( x => [ x , x + 1 ] ) ;
bar . trimLeft ( ) ;
arr . includes ( 2 ) ; | [x, x + 1]);
bar.trimLeft();
arr.includes(2);"> import "core-js/modules/es.array.flat-map.js" ; import "core-js/modules/es.array.unscopables.flat-map.js" ; import "core-js/modules/es.string.trim-start.js" ; foo . flatMap ( x => [ x , x + 1 ] ) ; bar . trimLeft ( ) ; arr . includes ( 2 ) ; |
La méthode usage-pure injecte des importations dans les polyfills pour les fonctionnalités non prises en charge qui sont utilisées dans votre code, sans attacher les polyfills à la portée globale mais en les important en tant que fonctions normales. Vous souhaiterez peut-être utiliser cette méthode si :
| Code d'entrée | Code de sortie |
|---|---|
foo . flatMap ( x => [ x , x + 1 ] ) ;
bar . trimLeft ( ) ;
arr . includes ( 2 ) ; | [x, x + 1]);
_trimLeftInstanceProperty(bar).call(bar);
arr.includes(2);"> import _flatMapInstanceProperty from "core-js-pure/stable/instance/flat-map.js" ; import _trimLeftInstanceProperty from "core-js-pure/stable/instance/trim-left.js" ; _flatMapInstanceProperty ( foo ) . call ( foo , x => [ x , x + 1 ] ) ; _trimLeftInstanceProperty ( bar ) . call ( bar ) ; arr . includes ( 2 ) ; |
Au cours des trois dernières années et demie, @babel/preset-env a montré tout son potentiel en réduisant la taille des bundles, non seulement en ne transpilant pas les fonctionnalités de syntaxe prises en charge, mais également en n'incluant pas les polyfills core-js inutiles.
Jusqu'à présent, Babel a proposé trois manières différentes d'injecter des polyfills core-js dans le code source :
useBuiltIns: "entry" de @babel/preset-env , il est possible d'injecter des polyfills auto-installables pour chaque fonctionnalité ECMAScript non prise en charge nativement par les navigateurs cibles ;useBuiltIns: "usage" de @babel/preset-env , Babel injectera uniquement des polyfills auto-installables pour les fonctionnalités ECMAScript non prises en charge, mais uniquement s'ils sont réellement utilisés dans le code source d'entrée ;@babel/plugin-transform-runtime , Babel injectera des polyfills "purs" (qui, contrairement à ceux auto-installés, ne polluent pas la portée globale) pour chaque fonctionnalité ECMAScript utilisée prise en charge par core-js . Ceci est généralement utilisé par les auteurs de bibliothèques.Notre ancienne approche présente deux problèmes principaux :
targets de @babel/preset-env avec des polyfills "purs", car @babel/plugin-transform-runtime est un package complètement distinct.core-js s'ils souhaitaient une intégration Babel. core-js est un bon polyfill complet, mais il ne répond pas aux besoins de tous nos utilisateurs.Avec ces nouveaux packages, nous proposons une solution à ces deux problèmes, tout en conservant une compatibilité ascendante totale.
Consultez notre CONTRIBUTING.md pour commencer à configurer le dépôt.
