Clarification: node-addon-api scope

[DaAitch]

There were a lot of cool discussions about what "node-addon-api" can be in the future, but I think we should make a decision which scope node-addon-api has, because I feel some of the issues are better implemented as another util library than in node-addon-api.

Some questions and examples:

A. Will node-addon-api be only a wrapper for napi in C?

If so, we should not implement any "utils", but focus on wrapping napi plus what C++ needs that C doesn't have:

• C stuff: (e.g. function pointer/data pointer) can be solved in a modern C++ way with templated callables and generic types, because this is how it would have been implemented in C++
• sub-classing: I think we have 2 classes
  • AsyncWorker: it make sense to provide it like this and have the hooks as virtual functions, but on the other hand I'm not feeling very comfortable that there is no functional way doing it, so the point is that composition should be preferred over inheritance or at least inheritance is an optional feature we can provide, too, but for me it's more the util part of it and composition should be default.
  • ObjectWrap: I love that pattern and concept. As we have object orientation in C++ and JS, this concept is integral part to bring those worlds together. Another reason to prefer node-addon-api over directly using napi.
• threading: we have Workers in Node and tsfn in napi. I can't remember any other threading feature in Node. Just thinking: it would be possible to spawn multiple Workers in Node and solve all problems synchronously, in JS or C++, but this makes everything too complicated. So tsfn is the only enabler that we can use threads now and the idea is clear. So after tsfn wrappers are implemented we are done with threading topics.
• node-addon-api micropackages like in Node: we can do new features and utils the usual way: create a new npm package and share with the community, so other packages or projects can import it, but node-addon-api stays small and focused on napi.

B. Will node-addon-api be a wrapper for C napi plus some helpful features

Hard to define what "helpful" is and also napi C users can't use it, so it's hard to have a focus here.

---

What do you think? For me "A" makes more sense and I can see that before long we have many npm packages like: napi-json, napi-rx, napi-copyable-reference, napi-functional-asyncworker, napi-threadpool and so on 😁 ... just dreaming.

[mhdawson]

I think the one thing to add to the discussion is that part of the goal was to make it easy to transition from nan. Now that does not mean that functionality from nan must be in node-addon-api directly but we would need to plan out where that added functionality might go.

Thinking off the top of my head I wonder if node-addon-api could the parent and then we could have node-addon-api-core which would be the wrapper. You could use node-addon-api if you wanted everything and it would pull in napi-copyable-reference etc. Or you could include specific ones. Not quite sure how that would all work but just another thought.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[mhdawson]

I think what the team has been thinking based on past discussions/decisions is

1. Mostly A, with some small additions. In particular to support transition from NaN.