关于前端:有没有可能让npmscripts更好维护

前言

当一个我的项目越来越大，然而团队对于我的项目目录配置、命名格调、模块划分、工程脚本等方面没有做好齐备的团队标准时，就会面临各种办法利用千人千面，接手和保护的心智累赘大的问题，其中 scripts 配置就是一个迭代不那么容易收敛的一项配置。比方张三某天开发了一段脚本，写入 xxx 配置进行应用(其实也是一段很有用的脚本)，除非我的项目有欠缺的开发文档，否则起初的人基本不晓得有这个性能，甚至基本不会想到去用，或者因为不晓得而又去从新造轮子 …

缘和？

最近在接手一个迭代了很久的我的项目时，上手看到的 package.json 是这样的：

"scripts": {
  "analyze": "cross-env ANALYZE=1 umi build",
  "start": "cross-env UMI_ENV=dev umi dev",
  "dev": "npm run start:dev",
  "start:dev": "cross-env REACT_APP_ENV=dev MOCK=none UMI_ENV=dev umi dev",
  "start:no-mock": "cross-env MOCK=none UMI_ENV=dev umi dev",
  "start:no-ui": "cross-env UMI_UI=none UMI_ENV=dev umi dev",
  "start:pre": "cross-env REACT_APP_ENV=pre UMI_ENV=pre umi dev",
  "start:test": "cross-env REACT_APP_ENV=test MOCK=none UMI_ENV=test umi dev",
  "start:lcic": "cross-env REACT_APP_ENV=dev MOCK=none UMI_ENV=lcic umi dev",
  "build:test": "cross-env UMI_ENV=test umi build",
  "build:pt": "cross-env UMI_ENV=pt umi build",
  "build:pre": "cross-env UMI_ENV=pre umi build",
  "build:prod": "cross-env UMI_ENV=prod umi build",
  "build:canary": "cross-env UMI_ENV=canary umi build",
  "build:hw": "cross-env UMI_ENV=hw umi build",
  "build:ms": "cross-env UMI_ENV=ms umi build",
  "deploy": "npm run site && npm run gh-pages",
  "gh-pages": "gh-pages -d dist",
  "i18n-remove": "pro i18n-remove --locale=zh-CN --write",
  "postinstall": "umi g tmp",
  "lint": "umi g tmp && npm run lint:js && npm run lint:style && npm run lint:prettier",
  "lint-staged": "lint-staged",
  "lint-staged:js": "eslint --ext .js,.jsx,.ts,.tsx",
  "lint:fix": "eslint --fix --cache --ext .js,.jsx,.ts,.tsx --format=pretty ./src && npm run lint:style",
  "lint:js": "eslint --cache --ext .js,.jsx,.ts,.tsx --format=pretty ./src",
  "lint:prettier": "prettier --check"src/**/*"--end-of-line auto",
  "lint:style": "stylelint --fix"src/**/*.less"--syntax less",
  "openapi": "umi openapi",
  "precommit": "","prettier":"prettier -c --write "src/**/*"",
  "pretest": "node ./tests/beforeTest",
  "test": "umi test",
  "test:all": "node ./tests/run-tests.js",
  "test:component": "umi test ./src/components",
  "tsc": "tsc --noEmit",
  "prepare": "husky install"
},

不晓得你看到这样的配置第一工夫反馈是怎么的，我的感触是“头皮发麻”。问题是，这些脚本别离是什么作用？什么场景下用？

如果正文就好了对不对

可是 package.json 它不容许写正文啊！

尝试

有没有可能，咱们能够像以下这样保护一个我的项目的 scritps 呢？这样接手的人也分明的晓得每个命令代表什么含意，同时也可能独自保护甚至复用在多个我的项目上。

// 如果有这么一个配置文件
[{
  cmd: 'start:dev',
  script: 'cross-env REACT_APP_ENV=dev max dev',
  desc: '启动本地开发环境，代理开发环境 API',
},
 {
   cmd: 'start:test',
   script: 'cross-env REACT_APP_ENV=test max test',
   desc: '启动本地开发环境，代理测试环境 API',
 }]

想法感觉还能够，然而怎么实现呢？粗略的设想一下先：

想法 1: 能不能拦挡 npm run xxx 动作，让执行 xxx 时去执行自定义的配置文件中的命令而不是package.json

想法 2: 还是用配置，既然想要优化这个过程，能不能只执行 app xxx (app 假如是我要做的这个工具)，那 run 也省掉了啊

论断是：

• 想法 1 通过一番搜刮资源和查找 npm 文档，发现并没有所谓运行 npm run xxx 之前能够染指的钩子，因而间接幻灭
• 想法 2 显然更好一点，然而 app 这个脚本就得装在全局了，否则实现不了 app xxx，要么就只能装在我的项目里通过 npx app xxx 去调用

期间还理解了 scripty 这个插件，发现它的过程很鸡肋，相当于把命令和脚本写了两遍，what？怎么可能，我那么懒！

因而通过尝试，只能采取想法 2 去实现这个性能了。

盘点需要

如上文的思路，一份配置文件必定是必要的，那么定义的状态就以上文的为基准了。

1. 我心愿能够提供针对不同构建工具 / 平台的通用命令集，比方本地启动命令

比方对于vite，通常是这样的：

vite

对于webpack，通常是这样的：

webpack-dev-server –mode development

对于 umi，最常见的是这样的：

cross-env UMI_ENV=dev umi dev

因而对于这些每个我的项目必备的命令，须要默认反对，就不必独自去写了

2. 既然我都要借助这个工具去晋升开发体验了，那对应的提醒是不是失去位，接手的人一步就能晓得所有命令的作用，比方：

3. 我能不能间接对老我的项目间接生成一套标准配置，我再去补充 desc 呢

实现

实现过程跟简略，最终就是间接采纳 child_process.exec 去执行了原始脚本：

executeScript(cmd: string) {exec(cmd, (err, sto) => {if (err) {Log.error(err.stack)
    } else {Log.info(sto)
    }
  })
}

健壮性目前还比拟欠缺，仅实现了上述几个需要点的根底性能，后续会进行欠缺。想要理解原理的能够看源码，整体实现就只有 100 多行代码，如有须要能够进行二次革新在企业外部推广应用。

应用

装置

npm i npm-scripts-proxy -g

生成模板

nsp init

写模板

// nsp.config.mjs
import {defineNSPConfig, presets} from 'npm-scripts-proxy'

export default defineNSPConfig({
  scripts: [
    {
      cmd: 'test',
      script: 'echo"Error: no test specified"',
      desc: '测试程序',
    },
    {
      cmd: 'build:test',
      script: 'node build.js',
      desc: '打包测试环境',
    }
  ],
  extends: presets.vite,
})

运行命令

nsp xxx

总结

其实到最初发现，这个工具就解决了一个问题，那就是题目提出的问题，可能它不是最好的解决方案，然而我的项目肯定是越做越大，必然是防止不了冗余且简单的。而如果在开发体验层面能够有一点点晋升，省去咱们接手我的项目时的一些“头皮发麻”的体验，写代码的情绪应该也会好一点吧。

最近在看美团 Rome 的演进史时，负责人讲到一些对于 Rome 在晋升开发体验层面的思考，感觉很不错，抛开晋升效率从而实现为企业降本增效不谈，“开发体验”何尝不是一个很重要且值得关注的事件呢。

一个问题

通过实现过程能够晓得，这个计划其实就是间接的去执行了 npm run xxx，从而不用保护package.json 中的配置，改去保护体验更好的配置形式。带来的问题是，已有的 CI 构建流程就须要替换，如果我的项目很多那就须要花相应的老本去革新，因而理论利用还须要综合评估一下才行，不过它的确无效的解决了一开始提到的问题，是一个值得尝试的计划。趣味的敌人能够去看源码，有更好计划的也能够评论区留言一下，让路过的开发者也借鉴一下。

查看源码