20200224 - ____啊大

[vianvio]

设计一套适合团队使用的react前端脚手架。要求至少达到以下几点：

1. 画一张技术模块图，描述脚手架整体构成，配文描述模块设计要解决的问题、场景和思路。
2. webpack区分日常、预发和线上三套环境配置，封装成npm模块，且能够反馈到代码运行时。同时要求日常不压缩代码或map，预发线上产出物一致。
3. 2的模块中需要包括以下配置：eslint，babel。
4. 基于2封装工程指令xxx(自定义，想个好名字，但是不要一周都在想名字)，包括但不限于：xxx dev(本地开发)；xxx build(复合命令，具体内容需要思考，主要为线上打包)；xxx create(复制github脚手架工程并下载到当前目录，可以暂时写死github仓库地址)
5. 建立react样例工程，工程代码附带hello world代码，并至少包括以下基础库：react-router; redux/mobx; axios; antd
6. 样例工程需要做到：样式主题统一配置；登陆态拦截；根据三套环境不同，在不改代码的情况下，发送不同地址的3个请求；
7. 样例工程可以自定义三套环境自己的webpack配置，自定义的配置需要无缝融入到4中的指令。

[m-yangyu]

一个简单的脚手架内容，具体详情在

https://github.com/HuskyToMa/mj_script.git

针对上面的图片一共分为了3个npm包，4个git仓库，除了mj_script的仓库以外还存在着另外3个仓库

1. https://github.com/HuskyToMa/mj_react
2. https://github.com/HuskyToMa/argv-store
3. https://github.com/HuskyToMa/mj-cli

主要使用的话提供了一个cli下载工具

npm i mj-cli -g

使用的话只需要一个命令

mj-cli create | mj-cli create -r yourname

[vianvio]

整体架子有了，但是实现上还是有点粗糙，有些点可以讨论，比如alias部分使用@和~的约定，是否会导致维护人员不容易上手？ cli部分包装的挺好，但是不使用社区方案的原因是什么？ webpack配置部分，三套环境拆分和业务工程可以自定义并没有体现出来，需要再思考一下。

可以对照参考https://github.com/risjs/ris

[m-yangyu]

三套环境的配置： 这个是存在的，webpack.config.js是所有的配置的导出，里面区分了dev以及非dev的环境，在业务代码中可以通过config下的devConfig, preConfig, ProConfig来重新定意思webpack配置，在build或者dev的时候会去查询当前文件是否存在，如果存在就拿来使用

cli不使用社区方案 这个是因为argv_store是我之前自己玩的时候就已经写好的库，针对这种简单的command 情况还是比较适用的，并且使用回调的方式在可读性上有一定程度的增加，我是觉得commander可读性稍微差一点，而且需要更高的复杂度的情况我会去考虑使用

对于粗糙的架子 我这边确实也有这样的感觉，有点半成品的味道，代理分割的并不是特别到位，还有点杂糅，我写完之后也还一直在想怎么优化下，这些希望大佬能给点意见

alias的配置 这个问题我这边是觉得并不会有太多问题，以为首先是约定式的内容，如果我们不存在这个约定，那么在写代码的时候本身也会为了方便而去写一个简单路径，而devConfig或者ProConfig中是可以配置的，但是这会存在同一个配置多次编写的问题，我需要修改下将所有的三种环境的配置文件整合成一个文件比较合适