node-addon-api: Missing module in Init

With the legacy api, I could obtain the addon module using this code:

void Init(Local<Object> exports, Local<Object> module) {
  NODE_SET_METHOD(module, "exports", CreateObject);
}
NODE_MODULE(NODE_GYP_MODULE_NAME, Init)

I need the module to obtain the addon filename (and folder) using this code:

std::string static GetModuleFilename(v8::Handle<v8::Object> module)
{
    Isolate* isolate = Isolate::GetCurrent();
    auto v8filename = module->Get(v8::String::NewFromUtf8(isolate, "filename"));
    auto filename = NodeTypes::FromV8String(v8filename);
    return filename;
}

How can I get the module and the filename at initialization time now?

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 36 (18 by maintainers)

Commits related to this issue

Most upvoted comments

@raffaeler it’s not node-gyp that does that but bindings. However, since bindings itself is loaded from another JS module, it is able to compute the package root directory and it searches a hard-coded list of (historical) paths for modules descending from that package root directory.

But check out https://github.com/nodejs/node/pull/37195 – let’s see how it goes 🤷

+1
gabrielschulhof on Feb 3, 2021

@gabrielschulhof frankly at this stage I can’t predict them. For sure Windows and Linux, but since my addon is a kind of “glue” between nodejs and .NET, it can potentially be used anywhere.

BTW by spying file activities I see a lot of addons making deep search through various folder to find themselves. This means that many others have the same need but just didn’t ask for it. Making this search leads to poor performance and can potentially break very easily. It is my belief that an official way to take the path would have beneficial effects on many addons.

+1
raffaeler on Feb 2, 2021

Hi @mhdawson I can think to other use-cases that will benefit from my request. For example if you want to host javascript code from native code (or any other language), the starting point cannot be javascript. (I want to remember that in my case I am not in control of javascript code at all)

Let’s see the issue from another perspective. Instead of the module, could you instead expose the information that the runtime environment has? (I need the addon path but others may be useful as well) I could see that even many js libraries are struggling in bulding paths without having precise/reliable information.

Thanks

+1
raffaeler on Jan 22, 2021

We’ve discussed this and don’t see any good options that fit with the abstractions we want to preserve in the API. Since there are alternatives which covers most of the use case, at this point unless there are more requests/cases where it blocks adoption its not in the work we are planning. Alternatives include:

  • Suggestion outlined in - https://github.com/nodejs/node-addon-api/issues/449#issuecomment-465838799
  • making the exports a function that can receive the module and return the bindings as a function of that -> const addon = require(‘./build/Release/addon.node’)(module); there are then several options of how to create the bindings with knowledge of the module object.
+1
mhdawson on Jan 22, 2021

@raffaeler @gabrielschulhof we’ve discussed in the recent N-API team meetings and @gabrielschulhof is trying out some different options and will post an update once he’s done that.

+1
mhdawson on Mar 4, 2019

Hey! Can you unmute me? I joined by phone.

+1
gabrielschulhof on Feb 25, 2019
Read more comments on GitHub
← node-addon-api: Intermittent failure in ThreadSafe function
node-addon-api: Napi::Env::GetAndClearPendingException assumes exceptions are Error objects →