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文档只是用一个入口起点
