自用react脚手架解析与思考

前端工程化

repo~：https://github.com/CNZN/k-r-cli

目的：开发脚手架js，上传npm托管；使用时下载到本地，终端输入相应命令，可以根据需求作出改进，或完成基本功能即可；

思路：根据前人的代码库及解析理清开发顺序，本地开发时注重交互质量和提供模版的多样化（模版两种拉取形式：1.跟随包在项目里加templates文件夹存放2.另开代码库线上链接下载拉取）.为了可以在终端流利的操控命令行使用Commander.js,设置用户界面和查询会话使用Inquirer.js。

预想困难：

1、与终端交互的实现

2、复制模版，就是复制文件的实现

所使用三方包： 

FECS	是基于 Node.js 的前端代码风格工具。
chalk	是一个颜色的插件。可以通过chalk.blue(‘hello world’)来改变颜色
Commander.js	node.js命令行界面的完整解决方案
Inquirer.js	仅仅给用户提供了一个漂亮的界面和提出问题流的方式
ncp	异步递归文件和目录复制
ora	主要用来实现node.js命令行环境的loading效果，和显示各种状态的图标等
pacote	从 npm 注册表中获取包清单和 tarball
Shelljs	本质就是基于node的一层命令封装插件，让前端开发者可以不依赖linux也不依赖类似于cmder的转换工具
figlet	字体特效
single-line-log	在控制台（或流）中同一行输出的Node.js模块。当您编写进度条或在较长的操作过程中显示状态消息时，此功能非常有用，支持多行
which	在 PATH 环境变量中查找指定可执行文件的第一个实例。不缓存结果，因此hash -r在 PATH 更改时不需要

创建目录开始码，npm init之后，因为要让程序终端识别我们的自定义指令，需要修改package.json,添加bin属性，增加自定义指令

了解贯穿始终的包，commander为简化使用，提供了一个全局对象

var program = require('commander');
program
  .version(require('../package').version)
  .usage('<command> [options] 快速启动项目') //-h 打印的用户提示

program
  .option('-n, --yourname [yourname]', 'Your name')
  .option('-g, --glad', 'Tell us you are happy')

初次与终端交互式，像vue、react都会有欢迎字样各种样式，这里引入figlet这个js，在npm官网查看使用实例。在交互页提升用户使用体验，这里使用figlet.textSync文本同步。效果图如下：

接下里是与开发者交互的终端，inquirer.prompt([]),接受的数组元素用来描述交互，结合异步获取交互详情，待后续操作

const question = [
    {
        name:'name',
        message:'请输入项目名称？', /* 是否进行 */
        default: 'react-demo'
    },{
        name:'author',
        message:'请输入作者？'
    },{
        type: 'list',
        name: 'target',
        message: 'please choose a template?',
        choices: ['webpack-react', 'webpack-react-ts'],
        default: 'tpl1'
    }
]

实现一个终端项目加载（webpack-plugin）

const chalk = require('chalk')
var slog = require('single-line-log');

class MycliConsolePlugin {
    
    constructor(options){
       this.options = options
    }
    apply(compiler){
        /* 监听文件改动 */
        compiler.hooks.watchRun.tap('MycliConsolePlugin', (watching) => {
            const changeFiles = watching.watchFileSystem.watcher.mtimes
            for(let file in changeFiles){
                console.log(chalk.green('当前改动文件：'+ file))
            }
        })
        /* 在一次编译创建之前 */
        compiler.hooks.compile.tap('MycliConsolePlugin',()=>{
            this.beginCompile()
        })
        /* 一次 compile 完成 */
        compiler.hooks.done.tap('MycliConsolePlugin',()=>{
            this.timer && clearInterval( this.timer )
            console.log( chalk.yellow(' 编译完成') )
        })
    }
    /* 开始记录编译 */
    beginCompile(){
       const lineSlog = slog.stdout
       let text  = '开始编译：'

       this.timer = setInterval(()=>{
          text +=  '█'
          lineSlog( chalk.green(text))
       },50)
    }
}
module.exports = RuxConsolePlugin

内容较多：参考诸位代码库及解析

本来无一物，何处惹尘埃；

本来没想要写脚手架的，唉，小孩咩亮说来话长；

从事前端开发一年多了，和众多小伙伴们一样一直很憧憬大厂，前段时正好给了我次面试的机会，总结以往经验还不够，又跑到掘金csdn翻看许多大厂面试总结，加上那段时间牛客、力扣不断的刷题，自信心还是要有的再不济也要好好表现自己；

面试也是正经面试，原生api包括应用场景与原理实现这些倒没什么问题，每次听到问题后我都会先吐一口气，娓娓道来，直到聊到框架；

关于主流框架，工作中一直都在用，写过的项目和自己的demo怎么说也超过双手加起之数，可偏偏雨渐渐～～脚手架的实现、框架中api实现、框架源码的阅读～连续的问题我难以招架···

最后咨询了下，我问贵公司fe对于框架的掌握有没有确切的标准呢，或者是深度，大哥想了想言：最起码对所使用框架的原理，和常用api的底层实现有自己的认识；

嗯，底层原理yyds！