Webpack ProvidePlugin vs externals?

C’est possible: vous pouvez inclure des bibliothèques avec un (c'est-à-dire utiliser une bibliothèque à partir d'un CDN) ou les inclure dans le bundle généré.

Si vous le chargez via la , vous pouvez utiliser l’option externals pour autoriser l’écriture de require(...) dans vos modules.

Exemple avec la bibliothèque de CDN:

  // the artifial module "jquery" exports the global var "jQuery" externals: { jquery: "jQuery" } // inside any module var $ = require("jquery"); 

Exemple avec la bibliothèque incluse dans le bundle:

 copy `jquery-git2.min.js` to your local filesystem // make "jquery" resolve to your local copy of the library // ie through the resolve.alias option resolve: { alias: { jquery: "/path/to/jquery-git2.min.js" } } // inside any module var $ = require("jquery"); 

ProvidePlugin peut mapper des modules à des variables (gratuites). Vous pouvez donc définir: "Chaque fois que j'utilise la variable (gratuite) xyz intérieur d'un module, vous (webpack) devez définir xyz pour require("abc") ."

Exemple sans ProvidePlugin :

 // You need to require underscore before you can use it var _ = require("underscore"); _.size(...); 

Exemple avec ProvidePlugin :

 plugins: [ new webpack.ProvidePlugin({ "_": "underscore" }) ] // If you use "_", underscore is automatically required _.size(...) 

Résumé:

• Bibliothèque à partir de CDN: utilisez externals option et les externals
• Bibliothèque du système de fichiers: incluez la bibliothèque dans le bundle. (Peut-être modifier resolve options de resolve pour trouver la bibliothèque)
• externals : Rendre les vars globaux disponibles en tant que module
• ProvidePlugin : Rendre les modules disponibles en tant que variables libres dans les modules

Il est intéressant de noter que si vous utilisez le ProvidePlugin en combinaison avec la propriété externals , cela vous permettra de passer jQuery à la fermeture de votre module webpack sans avoir à le require explicitement. Cela peut être utile pour le refactoring du code hérité avec beaucoup de fichiers différents référençant $ .

 //webpack.config.js module.exports = { entry: './index.js', output: { filename: '[name].js' }, externals: { jquery: 'jQuery' }, plugins: [ new webpack.ProvidePlugin({ $: 'jquery', }) ] }; 

maintenant dans index.js

 console.log(typeof $ === 'function'); 

aura une sortie compilée avec quelque chose comme ci-dessous passé dans la fermeture de webpackBootstrap :

 /******/ ([ /* 0 */ /***/ function(module, exports, __webpack_require__) { /* WEBPACK VAR INJECTION */(function($) { console.log(typeof $ === 'function'); /* WEBPACK VAR INJECTION */}.call(exports, __webpack_require__(1))) /***/ }, /* 1 */ /***/ function(module, exports, __webpack_require__) { module.exports = jQuery; /***/ } /******/ ]) 

Par conséquent, vous pouvez voir que $ fait référence à jQuery global / window du CDN, mais qu’il est transmis à la fermeture. Je ne suis pas sûr que ce soit une fonctionnalité prévue ou un hack de chance, mais cela semble bien fonctionner pour mon cas d’utilisation.

Je sais que c’est un ancien message, mais j’ai pensé qu’il serait utile de mentionner que le chargeur de script webpack peut être utile dans ce cas également. À partir des documents du webpack:

“script: exécute un fichier JavaScript une fois dans un contexte global (comme dans la balise script), les exigences ne sont pas analysées.”

http://webpack.github.io/docs/list-of-loaders.html

https://github.com/webpack/script-loader

J’ai trouvé cela particulièrement utile lors de la migration d’anciens processus de construction concatant des fichiers de fournisseurs JS et des fichiers d’application. Un mot d’avertissement est que le chargeur de script ne semble fonctionner qu’avec une surcharge de require() et ne fonctionne pas aussi loin que je puisse le dire en étant spécifié dans un fichier webpack.config. Bien que de nombreuses personnes prétendent que la surcharge est une mauvaise pratique, elle peut être très utile pour concilier un script fournisseur et application en un seul lot, tout en exposant les JS Globals qui n’ont pas à être intégrés à des packs Webpack supplémentaires. Par exemple:

 require('script!jquery-cookie/jquery.cookie'); require('script!history.js/scripts/bundled-uncompressed/html4+html5/jquery.history'); require('script!momentjs'); require('./scripts/main.js'); 

Cela rendrait $ .cookie, History et le moment disponibles globalement à l’intérieur et à l’extérieur de ce bundle, et regrouperait ces librairies avec le script main.js et tout ce qui est require fichiers.

Aussi, utile avec cette technique est la suivante:

 resolve: { extensions: ["", ".js"], modulesDirectories: ['node_modules', 'bower_components'] }, plugins: [ new webpack.ResolverPlugin( new webpack.ResolverPlugin.DirectoryDescriptionFilePlugin("bower.json", ["main"]) ) ] 

qui utilise Bower, va regarder le fichier main dans chaque fichier de bibliothèques require package.json. Dans l’exemple ci-dessus, History.js n’a pas de fichier main spécifié, le chemin du fichier est donc nécessaire.