|
1 | 1 | # 从零构建React工程 |
2 | | -1、新建一个文件夹ReactStudy |
3 | | -2、npm init -y |
4 | | -3、安装各种需要的依赖: |
| 2 | +1. 新建一个文件夹ReactStudy |
| 3 | +2. npm init -y |
| 4 | +3. 安装各种需要的依赖: |
5 | 5 | npm install webpack --save-dev |
6 | 6 |
|
| 7 | +# webpack的命令 |
| 8 | +1. webpack --config XXX.js //使用另一份配置文件（比如webpack.config2.js）来打包 |
| 9 | +2. webpack --watch //监听变动并自动打包 |
| 10 | +3. webpack -p //压缩混淆脚本，这个非常非常重要！ |
| 11 | +4. webpack -d //生成map映射文件，告知哪些模块被最终打包到哪里了其中的 |
| 12 | +5. webpack --progress //显示进度条 |
| 13 | +6. webpack --color //添加颜色 |
| 14 | +7. webpack --display-error-details //显示异常信息 |
7 | 15 |
|
| 16 | +# webpack-dev-server的命令 执行webpack.config.js 文件下的devServer |
| 17 | +1. webpack-dev-server --content-base /path/to/content/dir |
| 18 | +2. webpack-dev-server --disable-host-check |
| 19 | +3. webpack-dev-server --host 0.0.0.0 |
| 20 | +4. webpack-dev-server --port 8080 |
| 21 | +5. webpack-dev-server --open || webpack-dev-server --open 'Google Chrome' |
| 22 | +6. webpack-dev-server --hot-only |
| 23 | +7. webpack-dev-server --inline=false |
| 24 | +8. webpack-dev-server --lazy |
| 25 | +9. webpack-dev-server --progress |
| 26 | +10. webpack-dev-server --watch-content-base |
8 | 27 |
|
| 28 | + |
| 29 | +# module配置rule |
9 | 30 | test：用于匹配处理文件的扩展名的表达式，这个选项是必须进行配置的； |
10 | 31 | use：loader名称，就是你要使用模块的名称，这个选项也必须进行配置，否则报错； |
11 | 32 | include/exclude:手动添加必须处理的文件（文件夹）或屏蔽不需要处理的文件（文件夹）（可选）； |
12 | 33 | query：为loaders提供额外的设置选项（可选）。 |
13 | 34 |
|
14 | | -style-loader: 用来处理css文件中的url() |
15 | | -css-loader：用来将css插入到页面的style标签 |
| 35 | + |
| 36 | +# webpack的主要优势： |
| 37 | +1. 按需加载模块，按需进行懒加载，在实际用到某些模块的时候再增量更新 |
| 38 | +2. webpack 是以 commonJS 的形式来书写脚本，但对 AMD/CMD 的支持也很全面，方便旧项目进行代码迁移。 |
| 39 | +3. 能被模块化的不仅仅是 JS 了，能处理各种类型的资源。 |
| 40 | +4. 开发便捷，能替代部分 grunt/gulp 的工作，比如打包、压缩混淆、图片转base64等。 |
| 41 | +5. 扩展性强，插件机制完善 |
| 42 | + |
| 43 | + |
| 44 | +# 前端模块系统的演进 |
| 45 | +# CommonJS |
| 46 | +require("module"); |
| 47 | +require("../file.js"); |
| 48 | +exports.doStuff = function() {}; |
| 49 | +module.exports = someValue; |
| 50 | + |
| 51 | +## 优点： |
| 52 | +1. 服务器端模块便于重用 |
| 53 | +2. NPM 中已经有将近20万个可以使用模块包 |
| 54 | +3. 简单并容易使用 |
| 55 | + |
| 56 | +## 缺点： |
| 57 | +1.同步的模块加载方式不适合在浏览器环境中，同步意味着阻塞加载，浏览器资源是异步加载的 |
| 58 | +2. 不能非阻塞的并行加载多个模块 |
| 59 | + |
| 60 | +## 实现： |
| 61 | +1. 服务器端的 Node.js |
| 62 | +2. Browserify，浏览器端的 CommonJS 实现，可以使用 NPM 的模块，但是编译打包后的文件体积可能很大 |
| 63 | + |
| 64 | + |
| 65 | +# AMD(Asynchronous Module Definition) |
| 66 | +define("module", ["dep1", "dep2"], function(d1, d2) { |
| 67 | + return someExportedValue; |
| 68 | +}); |
| 69 | +require(["module", "../file"], function(module, file) { /* ... */ }); |
| 70 | +## 优点： |
| 71 | +1. 适合在浏览器环境中异步加载模块 |
| 72 | +2. 可以并行加载多个模块 |
| 73 | +## 缺点： |
| 74 | +1. 提高了开发成本，代码的阅读和书写比较困难，模块定义方式的语义不顺畅 |
| 75 | +2. 不符合通用的模块化思维方式，是一种妥协的实现 |
| 76 | +## 实现： |
| 77 | +1. RequireJS |
| 78 | +2. curl |
| 79 | + |
| 80 | +# CMD |
| 81 | +define(function(require, exports, module) { |
| 82 | + var $ = require('jquery'); |
| 83 | + var Spinning = require('./spinning'); |
| 84 | + exports.doSomething = ... |
| 85 | + module.exports = ... |
| 86 | +}) |
| 87 | +## 优点： |
| 88 | +1. 依赖就近，延迟执行 |
| 89 | +2. 可以很容易在 Node.js 中运行 |
| 90 | +## 缺点： |
| 91 | +1. 依赖 SPM 打包，模块的加载逻辑偏重 |
| 92 | +## 实现： |
| 93 | +1. Sea.js |
| 94 | +2. coolie |
| 95 | +# UMD |
| 96 | + |
| 97 | +# ES6模块 |
| 98 | +import "jquery"; |
| 99 | +export function doStuff() {} |
| 100 | +module "localModule" {} |
| 101 | +## 优点： |
| 102 | +1. 容易进行静态分析 |
| 103 | +2. 面向未来的 EcmaScript 标准 |
| 104 | +## 缺点： |
| 105 | +1. 原生浏览器端还没有实现该标准 |
| 106 | +2. 全新的命令字，新版的 Node.js才支持 |
| 107 | +## 实现： |
| 108 | +1. Babel |
0 commit comments