Vue Next Gitee

Posted on  by admin

Deploy

A Markdown application powered by vue, vditor and element. This app is a pure web page without any backend for data interactions. Thus, it’s convenient to build your own markdown app.

I designed the MarkBox with many necessary and useful Features as follows:. upload to your gitee repo. file manager (open an online file). Here is a demo without gitee storage.

For the security, I add a simple server that can valid your identification and send the private gitee/github info to you.

First, set a json of settings of pm2:.

Next, start your server by pm2:.

本文涉及到的 vue-next/scripts/release.js文件,整个文件代码行数虽然只有 200 余行,但非常值得我们学习。

歌德曾说:读一本好书,就是在和高尚的人谈话。 同理可得:读源码,也算是和作者的一种学习交流的方式。

阅读本文,你将学到:

环境准备之前,我们先预览下vuejs的发布流程。

GitHub

打开 vue-next(opens new window),开源项目一般都能在 README.md 或者 .github/contributing.md(opens new window) 找到贡献指南。

而贡献指南写了很多关于参与项目开发的信息。比如怎么跑起来,项目目录结构是怎样的。怎么投入开发,需要哪些知识储备等。

你需要确保 Node.js(opens new window) 版本是 10+, 而且 yarn 的版本是 1.xYarn 1.x(opens new window)。

你安装的 Node.js 版本很可能是低于 10。最简单的办法就是去官网重新安装。也可以使用 nvm等管理Node.js版本。

# 2.1 严格校验使用 yarn 安装依赖

接着我们来看下 vue-next/package.json 文件。

如果你尝试使用 npm 安装依赖,应该是会报错的。为啥会报错呢。因为 package.json 有个前置 preinstallnode ./scripts/checkYarn.js 判断强制要求是使用yarn安装。

scripts/checkYarn.js文件如下,也就是在process.env环境变量中找执行路径npm_execpath,如果不是yarn就输出警告,且进程结束。

如果你想忽略这个前置的钩子判断,可以使用yarn --ignore-scripts 命令。也有后置的钩子post。更多详细的可以查看 npm 文档(opens new window)

# 2.2 调试 vue-next/scripts/release.js 文件

接着我们来学习如何调试 vue-next/scripts/release.js文件。

这里声明下我的 VSCode 版本 是 1.59.0 应该 1.50.0 起就可以按以下步骤调试了。

找到 vue-next/package.json 文件打开,然后在 scripts 上方,会有debug(调试)按钮,点击后,选择 release。即可进入调试模式。

这时终端会如下图所示,有 Debugger attached. 输出。这时放张图。

学会调试后,先大致走一遍流程,在关键地方多打上几个断点多走几遍,就能猜测到源码意图了。

# 3 文件开头的一些依赖引入和函数声明

我们可以跟着断点来,先看文件开头的一些依赖引入和函数声明

# 3.1 第一部分

通过依赖,我们可以在 node_modules 找到对应安装的依赖。也可以找到其READMEgithub仓库。

# 3.1.1 minimist 命令行参数解析

简单说,这个库,就是解析命令行参数的。看例子,我们比较容易看懂传参和解析结果。

其中process.argv的第一和第二个元素是Node可执行文件和被执行JavaScript文件的完全限定的文件系统路径,无论你是否这样输入他们。

# 3.1.2 chalk 终端多色彩输出

简单说,这个是用于终端显示多色彩输出。

# 3.1.3 semver 语义化版本

语义化版本的nodejs实现,用于版本校验比较等。关于语义化版本可以看这个语义化版本 2.0.0 文档(opens new window)

版本格式:主版本号.次版本号.修订号,版本号递增规则如下:
主版本号:当你做了不兼容的 API 修改,
次版本号:当你做了向下兼容的功能性新增,
修订号:当你做了向下兼容的问题修正。
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面,作为延伸。

# 3.1.4 enquirer 交互式询问 CLI

简单说就是交互式询问用户输入。

# 3.1.5 execa 执行命令

简单说就是执行命令的,类似我们自己在终端输入命令,比如 echo 若川

看完了第一部分,接着我们来看第二部分。

# 3.2 第二部分

第二部分相对简单,继续看第三部分。

# 3.3 第三部分

这一块可能不是很好理解。inc是生成一个版本。更多可以查看semver文档(opens new window)

# 3.4 第四部分

第四部分声明了一些执行脚本函数等

# 3.4.1 bin 函数

获取 node_modules/.bin/ 目录下的命令,整个文件就用了一次。

相当于在命令终端,项目根目录 运行 ./node_modules/.bin/jest 命令。

# 3.4.2 run、dryRun、runIfNotDry

run 真实在终端跑命令,比如 yarn build --release

dryRun 则是不跑,只是 console.log(); 打印 'yarn build --release'

runIfNotDry 如果不是空跑就执行命令。isDryRun 参数是通过控制台输入的。yarn run release --dry这样就是truerunIfNotDry就是只是打印,不执行命令。这样设计的好处在于,可以有时不想直接提交,要先看看执行命令的结果。不得不说,尤大就是会玩。

main 函数末尾,也可以看到类似的提示。可以用git diff先看看文件修改。

看完了文件开头的一些依赖引入和函数声明等,我们接着来看main主入口函数。

# 4 main 主流程

第4节,主要都是main 函数拆解分析。

# 4.1 流程梳理 main 函数

上面的main函数省略了很多具体函数实现。接下来我们拆解 main 函数。

# 4.2 确认要发布的版本

第一段代码虽然比较长,但是还好理解。主要就是确认要发布的版本。

调试时,我们看下这段的两张截图,就好理解啦。

# 4.3 执行测试用例

# 4.4 更新所有包的版本号和内部 vue 相关依赖版本号

这一部分,就是更新根目录下package.json 的版本号和所有 packages 的版本号。

# 4.4.1 updatePackage 更新包的版本号

主要就是三种修改。

一图胜千言。我们执行yarn release --drygit diff 查看的 git 修改,部分截图如下。

# 4.4.2 updateDeps 更新内部 vue 相关依赖的版本号

一图胜千言。我们在终端执行yarn release --dry。会看到这样是输出。

也就是这句代码输出的。

# 4.5 打包编译所有包

# 4.6 生成 changelog

yarn changelog 对应的脚本是conventional-changelog -p angular -i CHANGELOG.md -s

# 4.7 提交代码

经过更新版本号后,有文件改动,于是git diff。是否有文件改动,如果有提交。

git add -Agit commit -m 'release: v${targetVersion}'

# 4.8 发布包

这段函数比较长,可以不用细看,简单说就是 yarn publish 发布包。我们 yarn release --dry后,这块函数在终端输出的如下:

值得一提的是,如果是 vue 默认有个 tagnext。当 Vue 3.x 是默认时删除。

也就是为什么我们现在安装 vue3 还是 npm i [email protected]命令。

# 4.9 推送到 github

我们 yarn release --dry后,这块函数在终端输出的如下:

到这里我们就拆解分析完 main 函数了。

整个流程很清晰。

用一张图总结则是:

看完vue-next/scripts/release.js,感兴趣还可以看vue-next/scripts文件夹下其他代码,相对行数不多,但收益较大。

# 5. 总结

通过本文学习,我们学会了这些。

同时建议自己动手用 VSCode 多调试,在终端多执行几次,多理解消化。

vuejs发布的文件很多代码我们可以直接复制粘贴修改,优化我们自己发布的流程。比如写小程序,相对可能发布频繁,完全可以使用这套代码,配合miniprogram-ci(opens new window),再加上一些自定义,加以优化。

关于小程序 ci 上传,再分享两篇文章。

小打卡小程序自动化构建及发布的工程化实践(opens new window) 虽然文章里不是最新的 miniprogram-ci,但这篇场景写得比较全面。

当然版本发布也可以用开源的 release-it(opens new window)。

同时,我们可以:

引入 git flow(opens new window),管理git分支。估计很多人不知道windowsgit bash已经默认支持 git flow命令。

引入 husky(opens new window) 和 lint-staged(opens new window) 提交commit时用ESLint等校验代码提交是否能够通过检测。

引入 单元测试 jest(opens new window),测试关键的工具函数等。

引入 conventional-changelog(opens new window)

引入 git-cz(opens new window) 交互式git commit

等等规范自己项目的流程。如果一个候选人,通过看vuejs发布的源码,积极主动优化自己项目。我觉得面试官会认为这个候选人比较加分。

看开源项目源码的好处在于:一方面可以拓展视野,另外一方面可以为自己所用,收益相对较高。

最后欢迎加我微信 ruochuan12(opens new window) 交流,参与 源码共读(opens new window) 活动,大家一起学习源码,共同进步。