Beta 版本相关问题汇总

[alvinhui]

Buglist:

• [x] 第二次进行「一键安装」的时候，之前的日志没有清空 image
• [x] AppWorks 单词大小写问题和 AppWorks 描述优化 image1 / image2
• [x] Node 版本管理功能，切换版本后返回管理页面，Node 版本号还是旧的 image

P0: 正式版本前必须修复(6.3)

• [x] 获取所有 Node.js 版本时间过慢，可以考虑添加缓存到本地 https://github.com/appworks-lab/toolkit/issues/5#issuecomment-848780975 @alvinhui
• [x] 一键安装的过程中的安装列表在切换后出现变化 https://github.com/appworks-lab/toolkit/issues/5#issuecomment-851327964
• [x] 切换 Node 版本的表单优化 https://github.com/appworks-lab/toolkit/issues/5#issuecomment-851331735
• [x] 切换 Node 版本的问题 https://github.com/appworks-lab/toolkit/issues/5#issuecomment-851345762
• [x] 工具列表添加跳转链接 https://github.com/appworks-lab/toolkit/issues/5#issuecomment-851367118 @alvinhui

P1:

• [ ] 安装套件时间过慢 https://github.com/appworks-lab/toolkit/issues/5#issuecomment-848532775
• [x] 多个 profile 共存时，虽然 nvm 已经安装到本地，但 Toolkit 提示没有安装 https://github.com/appworks-lab/toolkit/issues/5#issuecomment-848540852
• [ ] 应用第一次启动时，弹窗让用户输入密码，并保存密码(加密后的密码)至本地，避免后面需要操作权限时多次弹窗询问用户权限

[alvinhui]

安装套件的时候我这边存在一个现象，操作过程如下：

• 第一次安装套件，非常慢，等了五六分钟还没有安装好。于是我取消了安装；
• 然后我开启了网络加速（FQ），再操作安装套件，一下子就安装好了；
• 后续我本地卸载掉套件，再用 Toolkit 安装，即便是不加速，也很快；

我猜测可能 code 命令的实现有缓存机制。

从我们的角度，还是要想办法让这一过程更稳定更快。 我是比较建议说后续不依赖 code 命令行去实现这一功能的。 但是要看看投入产出比了。

[alvinhui]

问题

本地已安装了 nvm ，但是 toolkit 没有检测到：

这时候我再去点击安装 nvm ，安装完也还是显示未安装 nvm。

本地环境

看了一下检测是否安装 nvm 的实现，主要是读取 NVM_DIR

我本机有 .bashrc:

也有 .bashrc_profile：

初步判断

• 判断是否安装了 nvm 的实现需要优化一下，如何更好地检测用户有没有安装 nvm ？
• 安装 nvm 的 shell 脚本需要优化，如何处理好 .bashrc 和 .bashrc_profile 的关系？

[luhc228]

获取所有 Node.js 版本时间过慢，可以考虑添加缓存到本地

[alvinhui]

1. 在首页点击“一键安装”，取消勾选 "pack"，下一步的安装列表里面没有 "pack"
2. 切换到“Node 管理”，再切换到首页，安装列表里面出现了 "pack"

点击下面的图看效果：

[alvinhui]

切换版本功能优化：

这个“重装全局依赖”功能优化：需要备注说明一下是什么意思（目前来说大家有点看不懂它的作用），

如果是必要的，那么为什么还需要让用户来进行选择？

[alvinhui]

切换 Node 版本的时的问题：

1. 没有日志
2. 最后失败了

[alvinhui]

为列表里的工具添加链接跳转

[luhc228]

安装套件的时候我这边存在一个现象，操作过程如下：

• 第一次安装套件，非常慢，等了五六分钟还没有安装好。于是我取消了安装；
• 然后我开启了网络加速（FQ），再操作安装套件，一下子就安装好了；
• 后续我本地卸载掉套件，再用 Toolkit 安装，即便是不加速，也很快；

我猜测可能 code 命令的实现有缓存机制。

从我们的角度，还是要想办法让这一过程更稳定更快。 我是比较建议说后续不依赖 code 命令行去实现这一功能的。 但是要看看投入产出比了。

目前的实现方式是通过以下命令安装 VS Code 插件：

code --install-extension iceworks-team.iceworks

这个命令主要做了几个事情：

1. 下载一个 vsix 到本地
2. 解压 vsix 文件（可理解是 zip）
3. 分析里面的 extension.vsixmanifest、package.json 文件，收集该插件所依赖的插件（extensionDependencies 和 extensionPack），并重复上面的步骤1和2
4. 修改 extension.vsixmanifest 文件的路径，复制解压后的文件夹到 ~/.vscode/extensions/ 目录下
5. 修改 ~/.vsocde/extensions/.obsolete 文件（用于存放废弃的插件，如果插件 id 在此文件中，则在 vscode 插件市场中不会显示），确保刚才安装的插件 id 不在此文件中

从上面问题描述来看，主要是从网络下载 vsix 文件的时候比较慢（也就是第1步），而其他本地的操作速度理论上都很快。

解决下载慢的问题，可以把 *.vsix 放到 oss 上，toolkit 去 oss 上拉取 .vsix 到用户本地。

安装插件有两个方案：

方案一

调用 code --install-extension ./iceworks-team.iceworks-app-1.0.0.vsix 安装本地 vsix。

优点：借助于 code 命令去管理插件 缺点：目前需要自己实现的一套 Install Code to PATH

方案二

自己实现一套类似于 code 的功能去安装插件。

优点：不需要借助 code 命令，也不需要目前的自己实现的一套 Install Code to PATH 缺点：管理插件的实现还是有挺大的成本，看了看源码实现需要考虑挺多边界 case

个人推荐方案一

这里还有一个问题，如果新增/删除 appworks-pack 套件中依赖的插件，还需要更新 toolkit 的 data.json 和更新 oss 上的 vsix

[alvinhui]

@luhc228

方案一是缺点是：

1. 对 code 命令的依赖是不稳定的强依赖，你不了解 code 未来的逻辑变化，例如开发者本地 code 命令升级后参数变了
2. 网络的稳定性，无法指定源

方案二的缺点是:

1. 有实现和维护成本。看看能不能把 code 那个包引过来，例如把代码下载到本地之类。。。