Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
oyyd opened this issue Dec 10, 2021 · 11 comments
Closed

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

oyyd opened this issue Dec 10, 2021 · 11 comments

Comments

@oyyd
Copy link

oyyd commented Dec 10, 2021

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

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

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

@hyj1991
Copy link
Member

hyj1991 commented Dec 10, 2021

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

@hyj1991
Copy link
Member

hyj1991 commented Dec 10, 2021

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

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

@hyj1991
Copy link
Member

hyj1991 commented Dec 10, 2021

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

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

@oyyd
Copy link
Author

oyyd commented Dec 10, 2021

而对于如果构建环境和线上环境是跨 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
Copy link
Author

oyyd commented Dec 10, 2021

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

棒,之前没仔细看

@hyj1991

This comment has been minimized.

@hyj1991
Copy link
Member

hyj1991 commented Dec 10, 2021

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

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

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

@hyj1991
Copy link
Member

hyj1991 commented Dec 10, 2021

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

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

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

@hyj1991
Copy link
Member

hyj1991 commented Dec 13, 2021

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

@hyj1991 hyj1991 closed this as completed Dec 13, 2021
@fireairforce
Copy link

对于第二个问题,目前我这边使用 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
Copy link
Member

hyj1991 commented Dec 18, 2021

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants