# 为什么会有包管理器
# 大杂烩时代
设计之初，javascript只考虑浏览器中使用，不涉及访问本地文件。所以在早些时代的javascript没有包管理这一些概念；不同的模块比如moment，jquery都是通过script加载的方式一个一个怼到html中，变成window的一个个共享变量。好处是模块代码一把嗦？不用太多学习成本，就可以使用知名的模块，节省开发成本；坏处是管理复杂，容易出现变量冲突的情况，脚本依赖容易堵塞，x依赖y，或者y依赖x导致脚本顺序管理心智成本高等等。。
# npm出现
2009年大概，nodejs出现，基于v8引擎的js运行环境，让js运行在服务端的开发平台；随后针对nodejs设计的包管理器npm出现；所以并不能直接将npm包管理应用到html页面上（因为浏览器解析不了require）；大概2011-2012年，browserify出现并流行，于是也可以用require的语法进行组织各个模块编写前端打包，最终用browerify打包成浏览器可执行的语句。同时期也有个bower管理器，不啰嗦了。
# webpack
一个强大的模块处理工具，万物皆为模块。
# babel
babel并不是一门编程语言。我理解是专门将新一代的es语法通过翻译转换的形式转换成浏览器所支持的语法，以达到新特性功能兼容使用。
# 核心包
- @babel/core
- @babel/preset-env 需要翻译的语法配置清单，满足大部分的使用场景（新特性已确定，建议使用的）
- babel-loader 结合webpack处理js文件，兼容旧版本
# 几个问题
# package-lock.json的作用
问题是这样子的： 在项目里安装了webpack、babel之类的npm包，之后vuepress就跑不动了，怀疑是手动安装的版本跟vuepress的冲突了，在手动删除了npm包后重新install发现还是不行；最终百度后删除node_module + lock.json + 重新安装
尝试解释下：package-lock.json用于锁定项目的依赖版本，当有依赖的版本更新会自动更新json并下载依赖。当出现比原本依赖高/超出的版本时，比如手动指定@x.x.x，这个时候lock.json的校验会失效，默认用本地已下载的高版本，结果出现不适配报错的问题；所以需要强制npm cache clean --force，并且手动删除node_modules重新下载。
# node-modules下bin的作用，为什么有时候可以在终端执行webpack，有时候会报找不到
{
"scripts": {
"start": "webpack"
}
}
通过npm启动的script，会默认执行前加上node_modules/.bin，所以当我们执行npm run start，其实是执行了node_modules/.bin/webpack；
bin其实是一个软链，在package.json下定义bin，就会在安装的时候，自动软链过去。
// webpack
{
"bin": {
"webpack": "bin/webpack.js"
}
}