前言感觉这块也是一个知识点。虽然我不能系统地用xmind来总结每个知识点的系列关系，但只能看到一个，记住一个。什么是package.json？理解package.json是描述包和管理包的信息json文件。它用于npm。例如，您可以编写一个包并将其发送到npm。那么这个json就是记录这个包的信息，或者用vue脚手架开发，对于项目来说就是管理包的文件。npminstall会读取这个文件的denp配置包信息，然后下载包。我们使用shell窗口来输入，就是知道这个窗口里面的命令其实是执行shell命令的，也就是说在输入npminit之后，里面运行了一个sehll命令，这个命令调用系统创建文本命令，然后blahblah，最后输出到这个文件夹。dependenices和devDependenices这两个字段，从头到尾只知道dependenices的依赖包是本地的，在线开发需要，比如UI框架，而devDependenices的依赖包只有本地需要开发，例如eslint；（1）本地需求和在线开发需求是什么？我的理解是，npmrundev时，会加载这两个字段的所有依赖包，而npmrunbuild时，devDependenices的依赖包不会被打包进去，从而减小整个包的体积，访问速度更快一点（2）今天才发现版本被锁了。安装依赖的时候把包前面的倒三角去掉，版本会被锁定。那么这样做有什么用呢？？当你的同事拉取代码运行npminstall时，如果依赖包前面有一个倒三角，其实是默认拉取最新的包。如果它完成运行并推送代码，则会更新package.json。重点来了！依赖A的版本是1.0，匹配依赖B的版本是1.0，后来依赖B更新为2.0。当你安装依赖的时候，A还是1，但是B被你更新成了2，结果报错(3)instructions//Installthelatesttodependencies(default)npmixxxxx//Installthelatesttodependenciesnpmixxxxx-S//安装最新版本到dependenciesnpmixxxxx@2.0.0//安装最新版本到devDependensnpmixxxxx-Dbin在介绍这个字段之前，先给大家举个例子。在新电脑环境安装node时，如果安装node时没有配置PATH（环境变量地址），在shell窗口输入node-v时会报错说我找不到。配置完路径后，你只要填写安装目录路径就大功告成了。说完以上，回到这个垃圾箱。这个bin字段的作用其实也是类似的。在我们的依赖包中，比如gulp，就有这个bin字段的配置。一旦有了这个配置，其实我们在安装npmigulp的时候，它会读取这个字段，然后写一个文件到node_modules。bin文件夹（这个文件夹的由来是这样的）然后，当我们npmrundev的时候，我们都知道这段代码其实是运行了gulpdev-localinscripts，问题来了，我没有globalgulp安装，我没有配置PATH，为什么这样运行会报错！！！答案是，下面介绍一下大佬文章的解释（1）每次我们在scripts中运行一个属性（npmrun），实际系统会自动创建一个新的shell（一般是Bash），并执行指定的脚本命令。因此，任何可以在shell中允许的脚本都可以在npm脚本中编写。(2)特别地，npmrun创建的新shell将被添加到当前目录的node_modules/.bin子目录中的PATH变量中。执行完成后，PATH变量会恢复到原来的状态。即当前项目目录节点——modules/下的所有脚本。bin到PATH环境变量。)例如，我们应该这样写“脚本”：{"dev":"./node_modules/.bin/gulpdev-local","server":"gulpdev-local","build":"gulpdeploy&&gulpdev-server"}，但是有了这个机制，你可以"scripts":{"dev":"gulpdev-local","server":"gulpdev-local","build":"gulpdeploy&&gulpdev-server"}，你也可以想到webpack，我没有全局安装webpack，为什么我可以以依赖的形式安装webpack却可以执行，同理"scripts":{"dev":"webpack-dev-server--inline--progress--configbuild/webpack.dev.conf.js","start":"npmrundev","build":"nodebuild/build.js"}，未完待续参考这篇大哥【Node进阶】你该知道的NPM都在这里！
