node与nvm的约会
2024/09/09 5 mins read See this issue
# 陈年老博客
# npm package
Back
To Top
[!CAUTION]
# “ExperimentalWarning: The fs.promises API is experimental”
# 喵的一开始查遍资料,发现这个fs.promises玩意从低版本的npm / node编译环境里面就是个未投入生产的接口,而导致此次引发的血案,竟然是因为…
# 当前node的环境版本配置确实可能眼花缭乱(至少对于多项目管理或与其他业务公司驻场开发时的版本环境来说),各种不同的版本都有可能需要,无论高低来说都有可能,但新版本的话就不同,很少敢尝试使用最新的版本(主要还是怕埋雷,一不小心就是那个小白鼠…),为此,小弟经常固定几个版本使用:
<!-- 常用版本1 -->
node_v12.x@latest:https://registry.npmmirror.com/binary.html?path=node/latest-v12.x/
<!-- 常用版本2:该版本为适应兼容需要高npm依赖库版本而用,目前正转为主力版本使用测试中,截止当前仍是无任何异常,也向下兼容大数版本库(推荐) -->
node_v14.x@latest:https://registry.npmmirror.com/binary.html?path=node/latest-v14.x/
这时候有人就要说了,唉~那我同时都有需要这两个版本的node环境,那咋整? 别慌,这时候,他来了(建议使用安装版,自动适配加入环境变量)!
他是干啥作用的呢?他集: 1、安装切换多版本nodeJs于当前的系统中,提供多项目需要不同node版本; 2、快速便捷的无缝切换所需版本,只需一行命令即可; 3、提供:
<!-- 列出nvm所有命令 -->
1. nvm
<!-- 查看所有的node版本以及当前正在使用的node版本 -->
2. nvm list
<!-- 查看node所有可安装版本 -->
3. nvm list available
<!-- 设置nvm install node镜像地址(例:https://registry.npmmirror.com/node/14.19.1) [!!!截止2022.05.01,经小弟测试使用多轮,目前只支持默认nodejs官方仓库地址下载安装node,也就是说我们可能使用不上这项配置了...小弟估约由于国内大部分镜像仓库都开启了防异常流量的安全网关规则的原因导致此项配置属性几乎已失效,或者也有可能是小弟的食用姿势不对?]-->
4. nvm node_mirror
<!-- 设置npm链接镜像地址(例:https://registry.npmmirror.com/npm/版本号,此条貌似无效果,也有可能我的食用姿势不正确...)[!!!此属性同上node_mirror异常] -->
5. nvm npm_mirror
<!-- 安装指定版本node(例:nvm install 10.16.0)-->
6. nvm install
<!-- 食用指定版本node(例:nvm use 10.16.0)-->
7. nvm use
<!-- 卸载指定node版本(例:nvm uninstall 10.16.0)-->
8. nvm uninstall
<!-- 启 / 禁用node版本管理 -->
9. nvm on / nvm off
<!-- 设置nvm管理的不同版本的node的目录。如果未设置path,将显示当前根目录 -->
10. nvm root path
<!-- 设置用于下载的代理。 将url留空以查看当前代理。将url设置为“none”以删除代理(!!!此配置使用方式过于捣腾,而且同样存在node_mirror/npm_mirror的类似异常情况,不建议再折腾使用) -->
11. nvm proxy url
以上命令皆已知晓后,便可以下载第二版本node包,下载通常无需再下载安装文件类型的node,只需要解压包即可,例:https://registry.npmmirror.com/binary.html?path=node/v16.11.1/ 进入此页面后:
选择自己所需对应的node压缩包,下载完成后,解压至刚刚安装nvm的安装根目录下,并将解压出文件夹名称统一为v版本号格式,如下图:
后,执行:nvm list…
PS:切换版本时需注意,打开终端需以管理员模式打开,否则切换会出现 exit status 1的错误提示!
# 回到文章开头(不好意思,是我标题党了…):
[!CAUTION] ==ExperimentalWarning: The fs.promises API is experimental==
其实这一段报错并不会造成多大影响,也不会对已在生产的项目造成威胁,仅仅是个人在项目开发依赖编译启动过程中发现此警告,而追溯的一个原因…