entry points
入口起点(entry point)指示webpack应该使用哪个模块,来作为构建其内部依赖图的开始,webpack会找出有哪些模块和library是入口起点(直接和间接)依赖的
默认值是./src/index.js
,然而,可以通过再webpack配置中配置entry属性,来指定一个不同的入口起点(或者也可以指定多个入口起点)
webpack.config.js
module.exports = { entry: './path/to/my/entry/file.js' };
单个入口(简写)语法
用法:entry: string| Array
webpack.config.js
module.exports = { entry: './path/to/my/entry/file.js' };
entry
属性的单个入口语法,是下面的简写:
module.exports = { entry: { main: './path/to/my/entry/file.js' } };
当我们向entry
传入一个数组时会发生什么?向entry
属性传入【文件路径(file path)数组】将创建“多个主入口(multi-main entry)”。在我们想要多个依赖文件一起注入,并且将它们的依赖导向(graph)到一个“chunk”时,传入数组的方式就很有用
当我们正在寻找为【只有一个入口起点的应用程序或工具(即library)】快捷设置webpack配置的时候,这会是个很不错的选择。然而,使用此语法在扩展配置时有失灵活
对象语法
用法:entry: {[entryChunkName: string]: string| Array
webpack.config.js
module.exports = { entry: { app: './src/app.js', vendors: './src/vendors.js' } };
对象语法会比较繁琐。然而,这是应用程序中定义入口的最可扩展的方式
“可扩展的webpack配置”是指,可重用并且可以与其他配置组合使用。这是一种流行的技术,用于将关注点(concern)从环境(environment)、构建目标(build target)、运行时(runtime)中分离。然后使用专门的工具(如webpack-merge)将它们合并
常见场景
以下列出一些入口配置和它们的实际用例:
分离 应用程序【app】和 第三方库【vendor】入口
webpack
module.exports = { entry: { app: './src/app.js', vendors: './src/vendors.js' } };
这是什么?从表面上看,这告诉我们webpack从app.js
和vendors.js
开始创建依赖图(dependency graph)。这些依赖图是彼此完全分离、互相独立的(每个bundle中都有一个webpack引导(bootstrap))。?这种方式比较常见于,只有一个入口起点(不包括vendor)的单页面应用程序(single page application)中?!
为什么?此设置允许你使用CommonsChunkPlugin
从【应用程序bundle】中提取vendor引用(vendor reference)到vendor bundle,并把引用vendor的部分替换为__webpack_require__()
调用。如果引用程序bundle中没有vendor代码,那么我们可以在webpack中实现被称为长效缓存的通用模式
【TODO】:为了支持提供更佳vendor分离能力的DllPlugin,考虑移除该场景
多页面应用程序
webpack.config.js
module.exports = { entry: { pageOne: './src/pageOne/index.js', pageTwo: './src/pageTwo/index.js', pageThree: './src/pageThree/index.js' } }
这是什么?我们告诉webpack需要3个独立分离的依赖图(如上面的示例)
为什么?在多页面应用中,(译注:每当页面跳转时)服务器将为你获取一个新的HTML文档。页面重新加载新文档,并且资源被重新下载。然而,这给了我们特殊的机会去做很多事:
- 使用
CommonsChunkPlugin
为每个页面的应用程序共享代码创建bundle。由于入口起点增多,多页应用能够复用入口起点之间的大量代码/模块,从而可以极大地从这些技术中受益
根据经验:每个HTML文档只是用一个入口起点