I've seen many users just store the class constructor reference statically for later use. This will definitely cause issues if the addon is used in both master thread and worker threads. We shall document the best practice to prevent such pitfalls. Or was I just missed such docs?
@legendecas I was planning on writing a class Napi::Addon that would solve this problem by having all bindings be instance functions rather than static ones. However, I believe that it would be best to have https://github.com/nodejs/node/pull/30537/ (backport of instance data to v10.x) for that, so we can use napi_get_instance_data() for retrieving the addon instance in the implementation.
It turns out that adding such a class would mean that we'd have to pretty much duplicate the entire API for creating functions, classes, and property descriptors. So AFAICT it's best to do what #663 does, which is to make the data available on the Napi::Env.
Most helpful comment
@legendecas I was planning on writing a class
Napi::Addonthat would solve this problem by having all bindings be instance functions rather than static ones. However, I believe that it would be best to have https://github.com/nodejs/node/pull/30537/ (backport of instance data to v10.x) for that, so we can usenapi_get_instance_data()for retrieving the addon instance in the implementation.