考虑用 n-api 替代 nan，增加预构建过的 addon 产物

[oyyd]

现在项目里面使用的是 nan，也就是在部署的过程中，需要用 node-gyp 来构建产物。这在有些场景下可能会导致一些麻烦，比如：

1. 一些场景里，线上产物构建和生产环境部署是分开的，有可能因为 Node.js 版本不一致，导致生产环境服务起不来。
2. 构建环境需要准备好编译工具。特别是对于 windows 来说，准备环境很麻烦。

现在主流的 Node.js LTS 版本对 n-api 的支持已经比较完善了，如果能用 n-api 替代 nan 的话，问题 1 就能被解决（但可能还是需要确保其他代码 abi 稳定）；如果能再进一步直接在 npm 包里面分发构建产物的话，开发者也就不需要准备编译工具了。

[hyj1991]

N-API 现在还是没保证 v8.h 和 uv.h 的大版本 ABI 兼容吧，这样切 N-API 收益感觉不是很大。

[hyj1991]

其实你说的 1 这个问题使用了 N-API 也没法保证，如果是 major 版本之内的，构建环境和线上如果能保持 major 版本一致的话目前这个构建产物也是通用的（依靠 NODE_MODULE_VERSION 宏保证）

而对于如果构建环境和线上环境是跨 major 版本的，N-API 也不保证跨 major 版本的 abi 兼容吧，还是需要更新构建环境。

[hyj1991]

对于第二个问题，目前我这边使用 node-pre-gyp 分发几个主流 os 的预编译产物，所以其实也不需要本地安装编译环境，全部放到 npm 包里有体积太大的问题。

关于这个我其实在关注 optional dependencies 这个特性，现在 npm-os 里已经支持了针对 os 和 cpu 的 optional dependencies，如果后面把 node_module_version 也纳入进来，就可以去掉 node-pre-gyp 使用原生的 npm 进行分发了。

[oyyd]

而对于如果构建环境和线上环境是跨 major 版本的，N-API 也不保证跨 major 版本的 abi 兼容吧，还是需要更新构建环境。

我理解这是 n-api 要解决的根本问题，应该是能保证的吧？

This API will be Application Binary Interface (ABI) stable across versions of Node.js.

我看到的一些实践里面目前都是这样用的，在支持 n-api 的 Node.js 版本里面也没有碰到大问题（可能有些小问题、bug），相应的不用再根据 major 版本分发产物了。

[oyyd]

目前我这边使用 node-pre-gyp 分发几个主流 os 的预编译产物

棒，之前没仔细看

[hyj1991]

上面是我理解有误，node_api.h 应该是保证跨 major 版本的 abi 兼容性。

不过还是那个问题，我们在 addon 里还会涉及到 v8.h 以及 libuv.h，这两者实际上 nodejs 也没法做 abi 兼容，除非上游打算再做一层原语抽象，把 v8 和 libuv 做成可插拔的非必要依赖。

如果不解决这一层的抽象，N-API 对于 xprofiler 的意义就比较有限了。

[hyj1991]

目前 xprofiler 的预编译产物地址：

• github release page ：https://github.com/X-Profiler/xprofiler/releases/tag/v1.2.6
• 国内的镜像：https://npmmirror.com/mirrors/xprofiler/v1.2.6/

安装的时候指定 --xprofiler_binary_host_mirror 指向国内镜像是很快的：

npm install egg-xtransit --save --xprofiler_binary_host_mirror=https://npmmirror.com/mirrors/xprofiler

[hyj1991]

先关闭了，有其他问题欢迎探讨。

[fireairforce]

对于第二个问题，目前我这边使用 node-pre-gyp 分发几个主流 os 的预编译产物，所以其实也不需要本地安装编译环境，全部放到 npm 包里有体积太大的问题。

关于这个我其实在关注 optional dependencies 这个特性，现在 npm-os 里已经支持了针对 os 和 cpu 的 optional dependencies，如果后面把 node_module_version 也纳入进来，就可以去掉 node-pre-gyp 使用原生的 npm 进行分发了。

optional Dependencies 现在包管理器都应该支持的挺不错了: evanw/esbuild#789 (comment)

[hyj1991]

optional Dependencies 现在包管理器都应该支持的挺不错了: evanw/esbuild#789 (comment)

不是 CLI 的问题，是 npm-os 还没支持 node_module 宏，esbuild 本身只是一个 go binary 它是无所谓的，addon 除了 os 外还关注 runtime abi.