uni-app通过vue-cli命令行改造踩坑历险

事情是这样的,之前天然把uni-app和h-builder绑定在一起使用,直到编译h5也要注册,让我略感不适,再到后来做CI/CD编译,为了便捷的使得app敏捷可见,于是就有了本次踩坑改造,以下回溯坑点

发现身边事儿、聊点周奇遇，我是沈二，期待奇遇的互联网灵魂~、一起聊天吹水，探索新的可能~wx:breathingss，入圈吧！

开始

全局安装

npm install -g @vue/cli

创建uni-app

vue create -p dcloudio/uni-preset-vue my-project

坑点一

遇到的第一个坑点在此处,网络的问题,包貌似无法下载,gitee下载

vue create -p E:\works\uni-preset-vue-master my-project

目录结构和H-builder相比,内容放置在了src中,外层多了node的一些配置和包

坑点二

node-sass跟随node版本的问题一直是一个让人诟病的问题,特别是node-16经常遇到node-sass4.0不兼容问题,其他常规的vue项目做一下升级也就罢了,艰难的是@dcloudio包里使用了node-sass@4的内容, 方式用sass包直接替代，移除掉原本可能已经下载的node-sass包,具体的相关引用配置涉及如下：

  "postcss-comment": "^2.0.0",
  "postcss-import": "^15.1.0",
  "postcss-loader": "^7.3.3",
  "sass": "^1.49.8",
  "sass-loader": "^10.0.3",

如果你编译的时候发现，Node Sass version 6.0.1 is incompatible with ^4.0.0. 大概率就是这个问题引起的

Syntax Error: Error: Node Sass version 6.0.1 is incompatible with ^4.0.0.

坑点三

至于Unknown keyword formatMinimum 这个问题引起的因素挺难界定,至少是在找文档是找了半天愣是没有发现原因,乃至于CI/CD的时候一直无甚结果

error in ./src/App.vue?vue&type=style&index=0&lang=scss&
 Syntax Error: Error: Unknown keyword formatMinimum

最后就不得不吐槽神奇的npm的下包操作,如果换成yarn i或者pnpm i,你会神奇的发现,这个问题就不会再复现了,至于其他的降版本或者降低sass-loader之类的操作,貌似没什么具体的功效,最后贴个CI/CD的流水线编译结果。

槽点PS 为什么要提供HBuilderX可视化模式

1. 为了提升易用性，较低门槛

很多开发者对node不熟悉、对命令行有心理抵触。不要想当然认为所有开发者都会node，HBuilder有几百万开发者，其中掌握node的开发者连一半都占不到。

2. npm、github网络经常出问题

使用cli创建项目时，cli需要从npm安装，预置的项目模板选择从github下载，这些经常因为网络问题卡壳。可视化创建项目不存在这个问题。

3. 每个uni-app项目下都有一套编译器太麻烦

一个HBuilderX的开发者有非常多个uni-app项目，如果每个项目下放一套编译器，会有很多不合理： - 创建项目会非常慢 - 非常占用磁盘空间（uni-app的编译器有数万个文件） - 升级麻烦，兼容性问题多。cli项目下的编译器不会跟随HBuilderX升级而升级，只能开发者手敲npm命令升级。当HBuilderX升级后，有的uni-app项目的编译器未升级，有的升级了，报错时开发者很容易懵圈，给DCloud报bug时DCloud也懵圈。让ide版本、编译器版本、uni-app运行时这3者的版本保持一致，会减少非常多的问题。

把编译器内置到HBuilderX中，开发者创建项目时只需关心自己的业务代码，工程结构干净清爽。

各家小程序也都是这么做的，编译器在小程序开发工具里，创建项目时不会在项目下带一套编译器（小程序也是要把wxml等编译为js的）。

附语

总之VSCode始终是我谜之最爱,至于为啥要用HBuilderX,除非硬性要求,确实有点儿不太习惯网络编译服务这个概念，虽然它很棒、