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.