环境准备

首先要将自己的系统版本升级到 6.0.0.115 以上，系统版本过低可能会产生预期之外的问题。

然后找到“设置”>“隐私和安全”>“高级”菜单，打开“运行外部来源的扩展程序”

再去到应用市场尝鲜区里面下载 CodeArts IDE

到这里就做完了准备工作，就可以着手开发了。

开发流程

在桌面创建一个空文件夹，取个名字，比如叫做“my-project”

打开 CodeArts IDE，点“打开工程”

打开你桌面上的“my-project”工程

打开 CodeArts IDE 的终端

在 CodeArts IDE 的终端里面执行 npm install -g create-vite，把脚手架工具进行全局安装

在 CodeArts IDE 的终端里面执行 create-vite .，将当前目录初始化成一个 vue 工程

修改工程根目录里面的 package.json，把 rollup 替换成 wasm 版本的实现

在 CodeArts IDE 的终端里面执行 npm install，安装依赖

在 CodeArts IDE 的终端里面执行 npm run dev，启动 vite 的预览服务，项目可正常预览

常见问题

1. 为什么要把 rollup 换成 wasm 版本的实现？

vite 这个包，它底层有两个重要依赖：esbuild 和 rollup。这两个包一个是用 go 语言实现的、一个是用 rust 语言实现的，它们默认情况下是不能跨平台的。（注：这是当代 vite 的情况，等到下一代 vite 8 发布之后就不是这个情况了）

为了让 esbuild 能在鸿蒙上运行，我向 esbuild 项目提了 PR（链接），对它进行了鸿蒙适配，让它在鸿蒙上使用 wasm 版本的构建产物来跑。这是因为 go 语言编译器现在还不支持鸿蒙，所以只能拿 wasm 版本的构建产物来跑。经过测试，这个包在 OpenHarmony 和 HarmonyOS 上都能正常运行。

同样的，为了让 rollup 能在鸿蒙上运行，我也向 rollup 项目提了 PR（链接），也对它进行了鸿蒙适配。但我对 rollup 的处理策略跟 esbuild 不一样。由于 rust 交叉编译工具链和 napi-rs 框架已经支持鸿蒙，所以我直接用 rust 工具链编鸿蒙产物，直接把 rollup 编译成 rollup.openharmony-arm64.node，没有像 esbuild 那样使用 wasm 的产物。

这个 rollup.openharmony-arm64.node 文件，我在纯 OpenHarmony 系统上是测试了能正常使用的，但在商业发行版 HarmonyOS 上会因为系统的安全规格限制而无法正常使用。根因是这样的：当前 HarmonyOS 6.0 并不允许一个 hnp 通过 dlopen 加载外部 so，无论是否有签名都不允许加载。而 CodeArts IDE 里面的 Node.js 恰恰是以 hnp 形式集成进来的，因此在这个开发环境中我们没法加载任何 .node 文件。

为了规避这个问题，我提供的临时处理方案是用 overrides 字段把 rollup 直接替换成 wasm 版本实现（官方本身就有提供 wasm 版本实现，只需要改个包名就能用），因此在上面的开发流程才有这么一个奇怪的步骤。

2. 遇到了不允许执行 rename 命令的报错

这个是系统本身的限制。系统不做改变的话，我们作为用户也没法解决这个问题，我这里提供的也只是规避方案。

如果你遇到了这个报错，请这么处理：

1. 删除 npm 全局安装目录：rm -rf $(npm config get prefix)
2. 删除工程内的 node_modules：rm -rf ./node_modules
3. 重新安装你所需的 npm 包

为什么这么做能规避这个问题呢？因为 rename 这个行为一般发生在 npm 包的卸载和升级过程。如果我们把安装目录都清空了，就不存在卸载和升级过程了，就可以规避这个问题了。