一文详解如何使npm-scripts更好维护的配置方法

更新时间：2023年06月11日 08:53:56 作者：vannvan

这篇文章主要为大家介绍了如何使npm-scripts更好维护的配置方法详解，有需要的朋友可以借鉴参考下，希望能够有所帮助，祝大家多多进步，早日升职加薪

前言

当一个项目越来越大，但是团队对于项目目录配置、命名风格、模块划分、工程脚本等方面没有做好完备的团队规范时，就会面临各种方法应用千人千面，接手和维护的心智负担大的问题，其中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去实现这个功能了。

盘点需求

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

我希望可以提供针对不同构建工具/平台的通用命令集，比如本地启动命令

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

对于webpack，通常是这样的：

webpack-dev-server --mode development

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

cross-env UMI_ENV=dev umi dev

因此对于这些每个项目必备的命令，需要默认支持，就不用单独去写了

既然我都要借助这个工具去提升开发体验了，那对应的提示是不是得到位，接手的人一步就能知道所有命令的作用，比如：

我能不能直接对老项目直接生成一套标准配置，我再去补充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构建流程就需要替换，如果项目很多那就需要花相应的成本去改造，因此实际应用还需要综合评估一下才行，不过它确实有效的解决了一开始提到的问题，是一个值得尝试的方案。兴趣的朋友可以去看源码，有更好方案的也可以评论区留言一下，让路过的开发者也借鉴一下。

查看源码

以上就是一文详解如何使npm-scripts更好维护的详细内容，更多关于npm-scripts维护的资料请关注脚本之家其它相关文章！

您可能感兴趣的文章:

JS实现带动画的回到顶部效果
这篇文章主要为大家详细介绍了JS实现带动画的回到顶部效果，具有一定的参考价值，感兴趣的小伙伴们可以参考一下
2017-12-12
JS实现的点击按钮图片上下滚动效果示例
这篇文章主要介绍了JS实现的点击按钮图片上下滚动效果,涉及javascript事件响应及页面元素属性动态操作相关实现技巧,需要的朋友可以参考下
2019-01-01
Js实现网页键盘控制翻页的方法
这篇文章主要介绍了Js实现网页键盘控制翻页的方法,较为详细的分析了Js实现网页键盘控制翻页的原理与具体实现方法,非常具有实用价值,需要的朋友可以参考下
2014-10-10
JavaScript的防抖和节流案例
这篇文章介绍了JavaScript的防抖和节流案例的代码实现和概念.包含详细的代码,希望对你有所帮助
2021-06-06
javascript精确统计网站访问量实例代码
网站一般都有访问量统计工具，比较高效实用的工具多种多样，这篇文章主要介绍了javascript精确统计网站访问量实例代码，感兴趣的小伙伴们可以参考一下
2015-12-12
JS传参及动态修改页面布局
本篇文章主要介绍了JS传参及动态修改页面布局的相关知识。具有很好的参考价值。下面跟着小编一起来看下吧
2017-04-04
基于js实现的限制文本框只可以输入数字
本文主要介绍了js限制文本框只可以输入数字的实例代码，可复制直接调用函数实现其功能。需要的朋友可以看下
2016-12-12
Javascript 鼠标移动上去小三角形滑块缓慢跟随效果
一个tab选项卡，当鼠标移动上去时红色滑块跟随,在布局过程中经常会使用到，本文提供了详细的实现代码，感兴趣的朋友可以参考下
2013-04-04
JavaScript的变量声明提升问题浅析(Hoisting)
大家应该都只奥javascript的变量声明具有hoisting机制，JavaScript引擎在执行的时候，会把所有变量的声明都提升到当前作用域的最前面。网上关于JavaScript的变量声明提升问题的文章有很多，这篇文章将再次谈谈关于这方面的问题，有需要的朋友们可以参考借鉴。
2016-11-11
微信小程序实现搜索框功能及踩过的坑
这篇文章主要介绍了微信小程序实现搜索框功能及踩过的坑,本文通过实例代码给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下
2020-06-06