package.json 有什么作用？
每个项目的根目录下面，一般都有一个package.json文件，定义了这个项目所需要的各种模块，以及项目的配置信息（比如名称、版本、许可证等元数据）。
可通过
npm init
来创建
{
"name": "someone", //项目名称
"version": "1.0.0", //版本号
"description": "", //描述
"main": "index.js", //加载的入口文件
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1" //运行脚本命令的npm命令行缩写，通过npm test 执行
},
"dependencies": { //项目运行所依赖的模块
"express": "latest",
"MD5": "~1.2.0"
},
"devDependencies": { //项目开发所需要的模块。
"bower": "~1.2.8",
"grunt": "~0.4.1",
"browserify": "2.36.1",
"grunt-browserify": "~1.3.0",
},
"author": "", //作者名
"license": "ISC" //许可证
}
有了package.json文件，直接使用npm install命令，就会在当前目录中安装所需要的模块。
npm install --save app 与 npm install --save-dev app有什么区别?
- --save参数自动把模块和版本号添加到dependencies部分写入dependencies属性，--save-dev表示自动把模块和版本号添加到devdependencies属性。
- 前者是项目运行所依赖的模块，后者是项目开发所需要的模块。
- 正常使用npm install时，会下载dependencies和devDependencies中的模块，当使用npm install--production或者注明NODE_ENV变量值为production时，只会下载dependencies中的模块。
node_modules的查找路径是怎样的?
当前目录、上级目录，一层层往上查找。。。。最终到根目录
npm3与 npm2相比有什么改进？yarn和 npm 相比有什么优势?
npm2 安装依赖的时候比较简单直接，直接按照包依赖的树形结构下载填充本地目录结构。太深的目录树结构会严重影响效率，甚至在 Windows 下可能会超出系统路径限制的长度。另外，在 Windows 有删 node_modules 目录经历的可能都经历过漫长的等待。
npm3 安装时会按照 package.json 里依赖的顺序依次解析，遇到新的包就把它放在第一级目录，后面如果遇到一级目录已经存在的包，会先判断版本，如果版本一样则忽略，否则会按照 npm2 的方式依次挂在依赖包目录下。这种构建方式会几乎把所有包放在一级目录下，很大程度上提升了效率以及节省了部分磁盘空间。
yarn和npm的比较：
- 无论 npm 还是 Yarn 在执行包的安装时，都会执行一系列任务。npm 是按照队列执行每个 package，也就是说必须要等到当前 package 成功安装之后，才能继续后面的安装。而 Yarn 是同步执行所有任务，提高了性能。
npm 的输出信息比较冗长。在执行 npm install <package> 的时候，命令行里会不断地打印出所有被安装上的依赖。相比之下，Yarn 简洁太多：默认情况下，结合了 emoji （Windows 上 emoji 不可见）直观且直接地打印出必要的信息，也提供了一些命令供开发者查询额外的安装信息。
npm 和 Yarn 都是通过 package.json 记录项目需要拉取的依赖模块，不过在使用时，往往 package.json 中模块的版本号不太会写得非常确切，通常是定个版本范围。为了防止拉取到不同的版本，Yarn 有一个锁定文件 (lock file) 记录了被确切安装上的模块的版本号。每次只要新增了一个模块，Yarn 就会创建（或更新）yarn.lock 这个文件。这么做就保证了，每一次拉取同一个项目依赖时，使用的都是一样的模块版本。而 npm 要通过 shrinkwrap 命令生成 npm-shrinkwrap.json 文件，只有当这个文件存在的时候，packages 版本信息才会被记录和更新。
yarn 构建步骤如下：
- Resolution: 向仓库请求依赖关系
- Fetching: 看看本地缓存了没有，否则把包拉到缓存里
- Linking: 直接全部从缓存里构建好目录树放到 node_modules 里
webpack是什么？和其他同类型工具比有什么优势？
webpack 是一个现代 JavaScript 应用程序的模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成少量的 bundle - 通常只有一个，由浏览器加载。
- webpack 支持简单的不含变量的表达式
- webpack 提供了代码拆分的方案，可以将应用代码拆分为多个块（chunk），每个块包含一个或多个模块，块可以按需被异步加载。
- webpack 提供了模块热替换的能力，它使得在修改完某一模块后无须刷新页面，即可动态将受影响的模块替换为新的模块，在后续的执行中使用新的模块逻辑。
npm script是什么？如何使用？
npm 允许在package.json文件里面，使用scripts字段定义脚本命令。
scripts字段是一个对象。它的每一个属性，对应一段脚本。
{
"name": "someone", //项目名称
"version": "1.0.0", //版本号
"description": "", //描述
"main": "index.js", //加载的入口文件
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1", //运行脚本命令的npm命令行缩写，通过npm test 执行no test specified
“bulid” "mkdir some" //自定义命令需要通过npm run bulid来执行，创建some文件夹
},
}
gulp是什么？使用 gulp 实现图片压缩、CSS 压缩合并、JS 压缩合并
gulp是基于Nodejs的自动任务运行器， 它能自动化地完成 javascript/coffee/sass/less/html/image/css 等文件的的测试、检查、合并、压缩、格式化、浏览器自动刷新、部署文件生成，并监听文件在改动后重复指定的这些步骤。
gulpfile.js
var gulp = require('gulp') //导入gulp
var cssnano = require('gulp-cssnano') //导入css压缩包
var concat = require('gulp-concat') //导入文件合并包
var jsmin = require('gulp-uglify') //导入JS压缩包
var imgmin = require('gulp-imagemin') //导入图片压缩包
gulp.task('build:img',function(){ //图片压缩任务
gulp.src('./scr/img/*.jpg')
.pipe(imgmin())
.pipe(gulp.dest('./dist/img/'))
})
gulp.task('build:css',function(){ //css合并压缩任务
gulp.src('./scr/css/*.css')
.pipe(concat('all.css'))
.pipe(cssnano())
.pipe(gulp.dest('./dist/css/'))
})
gulp.task('build:js',function(){ //js合并压缩任务
gulp.src('./scr/js/*.js')
.pipe(concat('all.js'))
.pipe(jsmin())
.pipe(gulp.dest('./dist/js/'))
})
gulp.task('default',['build:img','build:css','build:js'])
