The node-addon-api team loves contributions. There are many ways in which you can contribute to node-addon-api:
node-addon-api is meant to be a thin convenience wrapper around N-API. With this in mind, contributions of any new APIs that wrap around a core N-API API will be considered for merge. However, changes that wrap existing node-addon-api APIs are encouraged to instead be provided as an ecosystem module. The node-addon-api team is happy to link to a curated set of modules that build on top of node-addon-api if they have broad usefulness to the community and promote a recommended idiom or pattern.
The N-API team considered a couple different approaches with regards to changes extending node-addon-api
This is probably our simplest option in terms of immediate action needed. It would involve landing any open PRs against node-addon-api, and continuing to encourage folks to make PRs for utility helpers against the same repository.
The downside of the approach is the following:
This involves us spinning up a new package which contains the utility classes and methods. This has the benefit of having a separate module where helpers which make it easier to implement certain patterns and idioms for native addons easier.
The downside of this approach is the following:
This doesn't require a ton of up-front work from the N-API WG. Instead of accepting utility PRs into node-addon-api or creating and maintaining a new module, the WG will encourage the creation of an ecosystem of modules that build on top of node-addon-api, and provide some level of advertising for these modules (listing them out on the repository/wiki, using them in workshops/tutorials etc).
The downside of this approach is the following: