Look at N-API to see if it would help our binding portablitiy

[nschonni]

Still experimental with 8, but it looks like they're trying to integrate the Nan approach (with some other stuff) into the platform https://nodejs.org/api/n-api.html

/cc @mgol and @saper who were talking about this in Slack too

[xzyfer]

I've been following N-API closely. My bet is the that the community is blocked until nan adds support. There is currently no tracking issue with nan yet.

[saper]

I do not think that squeezing N-API into NAN is possible.

I am looking right now if our low-level uv callback stuff can be converted into N-API, which offers some callback and async job handling.

[boingoing]

N-API is meant to be mostly a replacement for NAN in that N-API is designed to be non-leaky about V8 or engine details and provide a flat, stable ABI surface. An N-API enabled native module binary shouldn't have to be re-compiled to continue working with future versions of Node.js. But I'm not going to go completely into the sales pitch here, you can read about it. 😁

We (N-API team) have built a preliminary port of node-sass on top of N-API as part of our effort to understand the API surface used by native modules. We used this port and the port of some other modules to determine which areas to focus on converting to N-API. This port has all of the NAN and V8-specific code removed and replaced by N-API equivalents.

I doubt this port meets the quality level to go in as-is, but it would certainly be a springboard if someone on node-sass was serious about doing the conversion to N-API. 😄 Please take a look if you're interested. I will be happy to answer questions about the port, help with coding it, point to documentation/code, etc.

https://github.com/boingoing/node-sass/tree/napi

[nschonni]

@boingoing if Nan is replaced with the napi convention, would we still be able to produce builds compatible with at least the current LTS versions of Node (4+) or is this only going to work for 8+

[boingoing]

The N-API enabled module binary can be loaded by older Node versions as well (4 and 6) by relying on an NPM package. There are more details in the documentation of the package:

https://github.com/nodejs/node-addon-api

[saper]

Thank you @boingoing this is very helpful. From what I can see some libuv specific code is still left there (but that's no V8 and even not C++).

It looks fairly complete and maybe even works, nice! :)

[jasongin]

My bet is the that the community is blocked until nan adds support.

I'm one of the developers on the N-API project. Unfortunately, NAN cannot ever support N-API directly. NAN is only a partial abstraction over the V8 APIs: when you use NAN, you're still using a lot of V8-specific types and other constructs. N-API is a higher-level, more complete abstraction: when using N-API, you shouldn't need to even include v8.h at all or reference any types in the v8:: namespace. We realize that the magnitude of the differences will make porting existing native addon code more difficult, but that was a conscious tradeoff.

We discussed the possibility of branding the N-API C++ library as "NAN 3.0" with @kkoopa, the top contributor to NAN. (He has also been reviewing some of the N-API code.). While NAN has some precedent of breaking changes between major versions, this is more of a complete redesign than a "breaking change", so that branding didn't seem appropriate. Anyway, Node.js will need to continue to support native addons that use the V8 APIs for the foreseeable future, because some addons might not ever be updated to N-API since the changes are non-trivial. NAN should continue to support those addons the same way it does now.

[jasongin]

Sorry I was looking at an older version of this page and didn't see @boingoing's replies until after I posted mine. It looks like we've said mostly the same things!

[jasongin]

From what I can see some libuv specific code is still left there (but that's no V8 and even not C++).

Right, at this time it is not a goal for N-API to cover all of the libuv APIs. Currently, it just covers its async APIs, partly to provide a clear migration path from Nan::AsyncWorker. It's possible N-API could expand to cover more or all of libuv in the future, but there is no immediate need, because libuv APIs are very stable (unlike V8 which tends to make breaking changes often) and libuv is still used by most other forks of Node, even when the JS VM is swapped.

[jasongin]

Regarding the node-sass N-API fork @boingoing linked above, we might do some things differently now that the N-API project is more mature than we originally developed the fork. In particular, that fork is mostly using the C APIs, while we think most native addons will prefer to use the C++ APIs, because they are more concise and more similar to the V8/NAN style.

I'd assume you don't want to immediately take a dependency on a feature that is still has "experimental" status. The best case scenario from our point of view might be if the node-sass team could eventually maintain a branch that uses N-API, that is kept mostly up to date with development occurring in node-sass/master. I guess it could be staging for a future node-sass v5.x, or however you all want to manage it. But I understand you might not be ready for that just yet. Of course we'd appreciate feedback about anything we can do to improve the development or migration experience.

[saper]

Frankly, were libsass a C library, I would be happy to switch to 100% C for portability. We have lots of reports from various users where the binding does not even load and recompiling magically helps. I find it hard to keep compatibility with C++ runtimes working for everybody alike.

[boingoing]

Noticed this issue is still hanging-around. Is there anything we can do to help or any feedback on the particulars of the N-API?

We have a weekly working group meeting every Thursday at 1:30 Eastern / 10:30 Pacific US time if you're interested in sitting-in. We would be able to spend some time going over any issues you have adopting N-API either technical, philosophical, or whatever. 😀

Here are just a couple more notes for N-API.

We typically track N-API-specific issues in the abi-stable-node repo. Issues can also be opened in the ordinary nodejs/node repo, as well, with the n-api tag but abi-stable-node is really only used for discussions about N-API.
https://github.com/nodejs/abi-stable-node

There is official documentation for N-API in the node docs.
https://nodejs.org/dist/latest-v8.x/docs/api/n-api.html

We did mention the c++ wrapper for N-API which provides a very Nan-like interface and lives in a separate repo from nodejs/node (similar to the Nan shipping story). This can be used to bring N-API compatibility to versions of node without N-API, as well.
https://github.com/nodejs/node-addon-api

[xzyfer]

Hello, sorry for the silence. I've been on the job search and recently hurt my back 😱

I'm definitely interested in pushing this forward. We have some big changes landing in LibSass very soon which will results in node-sass@v5 and v6. I would N-API to land in node-sass@v5. I'll create a meta issue documenting the plan for v5 and v6 this weekend. I'll be sure to cc @boingoing

[xzyfer]

@boingoing I have a couple questions around N-API and Web Assembly. We've started looking into shipping node-sass as a WASM module for supported environments. However it appears our usage of libuv to schedule async execution of libsass could be a blocker.

I've been reading over the recent updates in N-API around C++ Promise and AsyncWorker support and I'm curious as to whether

• they're a replacement for directly interacting with uv_queue_*
• they place nice(r) with Web Assembly

[aduh95]

Now that Node 10 has been released, N-API is no longer experimental. So if WebAssembly is not the way to go, maybe we should give N-API a try.

@xzyfer Regarding your question on uv_queue_*, does this package answers your concerns: get-uv-event-loop-napi-h?

[xzyfer]

@nschonni also mentioned using https://github.com/nodejs/node-addon-api as a N-API shim for older versions of Node.

This is certainly a step towards WASM.

[xzyfer]

For those following along at home I've picked up work on this again in #2440. It's getting pretty close (I think).

I'm hoping to get N-API support out in a v5 beta.

[meteorsnows]

As previous, It seem the best time to migrate is around the corner. Node.js remove version dependencies