Refact/migrate to umi

[sorrycc]

Close #769

好处

1. 大量配置和 package.json 依赖减少
2. 无需手动注册 models
3. 无需 router.js，以及手动处理 model 和 route component 按需加载等
4. duck 模式的目录结构，更清晰写
5. query-string 无需引入和使用
6. PWA 等性能优化方案

前后对比

1. 启动时间，umi 启动并自动打开 dashboard 32s（开 dll 16s），关闭按需编译并自动打开 dashboard 41s（开 dll 21s），roadhog 版本启动 42s，开 dll 17s
2. 构建时间，umi 105.90s，开 eslint 校验 108.49s, roadhog 96.21s
3. 构建产物，js + css 部分，umi 6.32M, roadhog 6.67M
4. 构建产物文件数，umi 25 个，多了几个动态加载的 model，roadhog 23 个

其他调整

1. 把一些 dependencies 和 devDependencies 调整了位置，devDependencies 是工具，dependencies 是运行时依赖，比如 less-vars-to-js，dva-model-extend、cross-env
2. version 的发布机制换成 hash
3. alias 配在 .babelrc，这样 test 也可以用
4. /src/public -> /public，框架自动会 copy
5. /src/mock -> /mock，/mock 才会自动 reload
6. babel-polyfill -> @babel/polyfill
7. 全局 layout 放 layouts/index.js，基于约定
8. routers/error -> pages/404.js，基于约定
9. polyfill 放在 global.js，基于约定
10. test 随着文件走，比如 a.js，那么建个 a.test.js 做测试，而不要单独建一个 test 文件夹

[superlbr]

1. 依赖的安装时间上roadhog 144.61s, umi 212s
2. umi接管了antd的依赖?
3. Build 失败了，Failed to minify the bundle. Error: umi.9399d67b.js from UglifyJs
   Invalid assignment [umi.9399d67b.js:80441,30]
   

[sorrycc]

依赖的安装时间上roadhog 144.61s, umi 212s

umi 功能多，依赖多，时间长没办法的。

umi接管了antd的依赖?

antd 在 umi 里内置处理了，可写可不写，写了会用指定的依赖版本。

[sorrycc]

Build 失败了，Failed to minify the bundle. Error: umi.9399d67b.js from UglifyJs
Invalid assignment [umi.9399d67b.js:80441,30]

已修复，query-string@6 的问题。

[superlbr]

1. __umi.dll.js 能否gzip 下，这个大小相对于roadhog build:dll稍稍夸张了些
   
2. 开dll的时候，观感还是有些明显，页面切换的时候。虽然个人是技术狂热者，还是希望开发友好些
3. build 完部署上差异不大，roadhog还是领先一些...
   umi:

roadhog: 

[superlbr]

开dll的时候，页面切换的时候慢。。。

1. 进入dashboard后，切到user的页面:
   umi 36 个请求 传输 34.19 MB / 31.89 MB 完成：6.73 秒 （Compiling了好久呀）
   roadhog 23 个请求 传输 2.05 MB / 397.93 KB 完成：1.39 秒
2. 每次新加载一个页面，__umi.dll.js都需要加载一次。。。好浪费

[superlbr]

还有umi的进程，窗口关了，系统注销了，还在后台跑。。。成了孤儿进程，被init进程(进程号为1)接管
node /Users/dva/Developer/umi-antd-admin/node_modules/.bin/cross-env BABELRC=1 BROWSER=none HOST=0.0.0.0 umi dev

kill了两次。。。干净了
node /Users/dva/Developer/umi-antd-admin/node_modules/umi/lib/scripts/dev.js
/usr/local/bin/node /Users/dva/Developer/umi-antd-admin/node_modules/umi/lib/scripts/realDev.js

[sorrycc]

umi 36 个请求 传输 34.19 MB / 31.89 MB 完成：6.73 秒 （Compiling了好久呀）。roadhog 23 个请求 传输 2.05 MB / 397.93 KB 完成：1.39 秒

这是一个算了 dll，另一个没有算？

每次新加载一个页面，__umi.dll.js都需要加载一次。。。好浪费

dll 我给加个缓存。

还有那个umi的进程，窗口都关了，vs code都关了，注销了，竟然还在后台跑着。。。变成了孤儿进程，被init进程(进程号为1)收养。。。

有重现步骤吗？我用 Control+C 关没有遇到这个问题。

[sorrycc]

按需编译可通过 COMPILE_ON_DEMAND 环境变量关闭。

$ COMPILE_ON_DEMAND=none npm start

[superlbr]

这是一个算了 dll，另一个没有算？

1. 嗯，因为这是打开第二个页面，dll缓存了，而且dll也有gzip
   

有重现步骤吗？我用 Control+C 关没有遇到这个问题。

2. 怀疑没有优雅退出，有没有守护进程?

[sorrycc]

出现 Compiling... 就是因为 umi 默认开了按需编译的原因，默认只编译请求过的页面。

[sorrycc]

怀疑没有优雅退出，有没有守护进程?

你是 control+c 退的？

[superlbr]

你是 control+c 退的？

各种意外的退出情况吧

[superlbr]

ali-oss 引入也有问题, build不出来，内部协商？#768

import OSS from 'ali-oss'
const OssWrapper = OSS.Wrapper

const client = new OssWrapper({
  region: 'oss-cn-hangzhou',
  accessKeyId: 'xxx',
  accessKeySecret: 'xxx',
  bucket: 'xxx',
})
client.list({
  prefix: 'xxx',
})

[jincan39]

@sorrycc 成哥 model怎么移到pages下面了，只有共享的model放在model文件夹下？

[superlbr]

@jincan39 duck 模式的目录结构，这样对应的模块东西都放在一起，便于修改、整理、移动，结构更清晰，不然东一块西一块，还要到处找

[jincan39]

@superlbr duck目录不就应该是state view 分离么；之前dva示例挺好的state都放在了model文件夹下。若是model分散在每个page下，redux单一状态树显得不清晰了，model是不是有点不便于复用了？（实际项目中一个page对应多个model）https://github.com/FortechRomania/react-redux-complete-example

[superlbr]

@sorrycc 那个build version没了。。。

[superlbr]

@sorrycc model的复用改如何处理，比如一个page对应多个model

[sorrycc]

model的复用改如何处理，比如一个page对应多个model

复用的 model 放上放，多个 page 复用，就放 src/models 里。

那个build version没了。。。

version 和 hash 的功能感觉重复？

[superlbr]

model的用法

翻到了umijs/umi#171

version 和 hash 的功能感觉重复？

version的好处，一眼从url看出版本算不算

[sorrycc]

更新 umi@1.1.4，dll 文件有缓存和 gzip 压缩了。

[superlbr]

@sorrycc