原生CLI指令构建npm run减少硬盘node_modules的开销

原生CLI指令构建npm run减少硬盘node_modules的开销

目录

原生CLI指令构建npm run减少硬盘node_modules的开销

一、vue-cli-service的本质及其原生指令

二、vue-cli-service原生指令的现实意义

三、vue-cli-service原生指令减少node_modules依赖的磁盘开销

        3.1、文件serve.cmd开始启动原生开发服务器CLI指令：

        3.2、文件build.cmd开始启动原生“生产环境”分发服务的CLI指令：

        3.3、每个工程路径根下简单复制这两个文件即可

        3.4、vscode或操作系统运行的终端控制台中分别运行它们，轻松搞定

四、效益

4.1、“共享依赖树”及其进程

4.2、减少了“热启动”编译日志冗余，方便浏览控制台的历史

喜欢的，就收藏并点个赞，鼓励我继续技术的原创写作：

---

一、vue-cli-service的本质及其原生指令

       在上一篇《vue执行配置选项npm run serve的本质》 中，我们分享了vue-cli-service的本质，及其原生指令为：

开发环境，npm run serve 的原生CLI命令行脚本为：

node .\node_modules\@vue\cli-service\bin\vue-cli-service.js serve
 

同理，生产环境，进行分发时，npm run build 的原生CLI命令行脚本为：

node .\node_modules\@vue\cli-service\bin\vue-cli-service.js build

       那么，它在现实中有什么意义呢？

二、vue-cli-service原生指令的现实意义

       先来看图说话：

       @vue/cli安装并生成vue项目后，node_modules的依赖树，经过构建工具这么一折腾，其磁盘“缓存”剧增。

       试想，如果每个工程，都这么部署，那么你如果构建的项目稍微一多，那么磁盘分卷的空间，将会很快吃紧，一两个T的固态硬盘空间很快耗尽。

       利用vue-cli-service的本质及其原生指令，可以很好地解决这一困惑，如下。

三、vue-cli-service原生指令减少node_modules依赖的磁盘开销

       我们已经知道：

{
    "name": "testtest",
    "version": "0.1.0",
    "private": true,
    "scripts": {
        "serve": "vue-cli-service serve",
        "build": "vue-cli-service build",
        "lint": "vue-cli-service lint"
    },
    "dependencies": {
        "core-js": "^3.6.5",
        "vue": "^2.6.11",
        "vue-router": "^3.2.0",
        "vuex": "^3.4.0"
    },
    "devDependencies": {
        "@vue/cli-plugin-babel": "~4.5.0",
        "@vue/cli-plugin-eslint": "~4.5.0",
        "@vue/cli-plugin-router": "~4.5.0",
        "@vue/cli-plugin-vuex": "~4.5.0",
        "@vue/cli-service": "~4.5.0",
        "@vue/eslint-config-prettier": "^6.0.0",
        "babel-eslint": "^10.1.0",
        "eslint": "^6.7.2",
        "eslint-plugin-prettier": "^3.3.1",
        "eslint-plugin-vue": "^6.2.2",
        "less": "^3.0.4",
        "less-loader": "^5.0.0",
        "prettier": "^2.2.1",
        "vue-template-compiler": "^2.6.11"
    },
    "eslintConfig": {
        "root": true,
        "env": {
            "node": true
        },
        "extends": [
            "plugin:vue/essential",
            "eslint:recommended",
            "@vue/prettier"
        ],
        "parserOptions": {
            "parser": "babel-eslint"
        },
        "rules": {}
    },
    "browserslist": [
        "> 1%",
        "last 2 versions",
        "not dead"
    ]
}
 

        其中，脚本命令可以做如下替换。

        原本：

    "scripts": {
        "serve": "vue-cli-service serve",
        "build": "vue-cli-service build",
    },

        可以替换为控制台命令：

node ..\node_modules\@vue\cli-service\bin\vue-cli-service.js serve
node ..\node_modules\@vue\cli-service\bin\vue-cli-service.js build

        那么，我们只需用文本编辑器，编辑两个操作系统的“批处理”可执行文件，即可。

        步骤：

        3.1、文件serve.cmd开始启动原生开发服务器CLI指令：

# serve.cmd开始启动原生开发服务器CLI指令:
node ..\node_modules\@vue\cli-service\bin\vue-cli-service.js serve

        3.2、文件build.cmd开始启动原生“生产环境”分发服务的CLI指令：

# build.cmd开始启动原生“生产环境”分发服务的CLI指令:
node ..\node_modules\@vue\cli-service\bin\vue-cli-service.js build

        3.3、每个工程路径根下简单复制这两个文件即可

        当然，如果你熟悉操作系统command脚本，也可直接修改“共享依赖”.\bin下的vue-cli-service.cmd和vue-cli-service这两个文件，修改其中的vue-cli-service.js的路径指向：

         这属于操作系统方面的知识，这里就不再赘述了。

         注意，批处理文件应当存为ANSI编码而非UTF8或Unicode，否则你加入的中文备注运行时会现实乱码：

        当然，在 Node.js 模块系统中，如果 require 的模块不是核心模块，而且没有 './' 之类的开头，那就需要从当前 package 的 node_modules 里面找，找不到就到当前 package 目录上层 node_modules 里面取... 一直找到全局 node_modules 目录。这样找到的往往是文件夹，所以接下来就是处理一个文件目录作为 Node 模块的情况。如果文件目录下有 package.json，就根据它的 main 字段找到 js 文件。如果没有 package.json，那就默认取文件夹下的 index.js。由于 webpack browsersify 等模块打包工具是兼容 node 的模块系统的，自然也会进行同样的处理流程。不同的是，它们支持更灵活的配置。比如在 webpack 里面，可以通过 alias 和 external 字段配置，实现对默认 import 逻辑的自定义。webpack.config.js,......,但配置起来复杂，而且全部需要Node.js全局依赖的支持，麻烦、不简洁，而且失去了灵活性。

        3.4、vscode或操作系统运行的终端控制台中分别运行它们，轻松搞定

四、效益

4.1、“共享依赖树”及其进程

 

 

4.2、减少了“热启动”编译日志冗余，方便浏览控制台的历史

        代码更新的响应式，仍然有效：

 

4.3、还能同时满足局部项目package.json等配置的灵活性

喜欢的，就收藏并点个赞，鼓励我继续技术的原创写作：

vue执行配置选项npm run serve的本质_pulledup的博客-CSDN博客