Beta 版本相关问题汇总 about apptoolkit HOT 9 CLOSED

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

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

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

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

from apptoolkit.

问题

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

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

本地环境

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

我本机有 .bashrc:

也有 .bashrc_profile：

初步判断

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

from apptoolkit.

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

from apptoolkit.

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

点击下面的图看效果：

from apptoolkit.

切换版本功能优化：

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

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

from apptoolkit.

切换 Node 版本的时的问题：

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

from apptoolkit.

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

from apptoolkit.

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

• 第一次安装套件，非常慢，等了五六分钟还没有安装好。于是我取消了安装；
• 然后我开启了网络加速（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

from apptoolkit.

@luhc228

方案一是缺点是：

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

方案二的缺点是:

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

from apptoolkit.