Missing module in Init

[raffaeler]

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?

[mhdawson]

If I remember correctly there was a discussion around including the module or not and the the decision was to drop the module from the parameters in order to avoid tying N-API to the Node.js module implementation.

It sounds like the main thing you want to figure out is the path as the name itself you probably can already figure out. Right? What are you using the path for?

[raffaeler]

@mhdawson Thank you Michael.
You are right, the main reason is obtaining the path of the addon itself. How can I get that?
I have a configuration file in that directory that I have to parse to retrieve a number of parameters.

But module can give me access to the require function as well as other symbols. The problem in dropping support for Module is the inability to easily migrate the addon. I substantially stopped at the very beginning, when writing the Initialization function.... it is so frustrating...

[mhdawson]

@raffaeler sorry to hear its been a bad start. I wish I better remembered the discussion as I know the concern was raised about not having access to the module and in the end there was an answer as to why it was thought it would not be an issue. @digitalinfinity any chance you remember?

What other info do you need from the module for the addon?

[raffaeler]

My codebase currently retrieves dirname, filename and the require function.
Filename is easy to replace with a preprocessor definition __FILE__.
By recursivly inspecting the global object I am seeing that require is also available via process.mainModule.require but I didn't test it. Can I replace it with this one?
I know there are also other symbols registered there but I currently can't know if they will be useful for the improvements I planned.

FYI I need a solution that works both in a plain nodejs environment but also in Electron. I had problems in the past with Electron because it sets differently the "current directory".

[gabrielschulhof]

@raffaeler another reason we dropped support for v8::Local<v8::Object> module is that most native addons are fronted by a JavaScript module. So, you don't normally have index.node in your npm package, but you have build/Release/addon.node and index.js which basically does

const addon = require('./build/Release/addon');
...
module.exports = addon;

So, if your addon also uses the index.js/./build/Release/addon.node setup, you could do a bit of ping-pong: Your addon provides a single binding which accepts the exports and the path, and initializes the exports in that binding as you normally would. From the JS side this would look like this:

const path = require('path');
const addonPath = path.join('.', 'build', 'Release', 'addon.node');
const addon = require(addonPath);
addon.initialize(addon, path.resolve(path.join(__dirname, addonPath)));
// Now `addon` is ready for use.

On the C++ side, you would make the following change:

From:

namespace {
Napi::Value Init(Napi::Env env, Napi::Object exports) {
  exports["doSomething"] = Napi::Function::New(env, DoSomething);
  exports["doSomethingElse"] = Napi::Function::New(env, DoSomethingElse);
  return exports;
}
}  // end of anonymous namespace

NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init)

To:

namespace {
Napi::Value Initialize(const Napi::CallbackInfo& info) {
  Napi::Object exports = info[0].As<Napi::Object>();
  Napi::String configPath = info[1].As<Napi::String>();
  // Do something with `configPath`.
  exports["doSomething"] = Napi::Function::New(env, DoSomething);
  exports["doSomethingElse"] = Napi::Function::New(env, DoSomethingElse);
}
Napi::Value Init(Napi::Env env, Napi::Object exports) {
  exports["initialize"] = Napi::Function::New(env, Initialize);
  return exports;
}
}  // end of anonymous namespace

NODE_API_MODULE(NODE_GYP_MODULE_NAME, Init)

[raffaeler]

@gabrielschulhof I don't get your solution.

1. I have no control over the js file that will use the addon, so I must minimize all the required javascript code to initialize the addon
2. I am not looking the module for the main module (I already can get it from process.mainModule.filename), but I need the exact path of the native addon at runtime which presumably will be something like someproject/node_modules/myaddon. I have a configuration file to read from there and several dlls to load out of the nodejs mechanism (I host the whole coreclr).

Thanks to the legacy API (and using Module), I currently have access to the runtime addon binary path. I am just trying to find a migration path for N-API.

I don't want to give for granted the positions on the hard disks as I found that they directories are treated differently from Electron and this can be true also for other apps/frameworks.

FYI Once I will get over this problem, I am still not sure to be able to migrate to the new API as I need to enqueue calls to the main node thread with libuv. I am not sure I will find all the API I need.

[legendecas]

FYI Once I will get over this problem, I am still not sure to be able to migrate to the new API as I need to enqueue calls to the main node thread with libuv. I am not sure I will find all the API I need.

If I understand your question correctly, I'd believe Thread Safe Function is what you expected.

[gabrielschulhof]

@raffaeler can you embed the configuration file into the native addon as part of the build process?

You can use the N-API thread-safe function to call a JavaScript function from any thread. Although the documentation marks it as experimental, we have PRs on the way to mark it as stable.

There's an example that illustrates its use.

[raffaeler]

@legendecas @gabrielschulhof Thank you. I currently manage my own functions queue. When an event handler of any asynchronous function on the CLR side completes, I marshal the results on the Node/C++ side and enqueue the results in my queue. Then, on the main libuv thread, I get the bucket, map it to a function and invoke it.
I have to investigate if I can use those functions to reproduce the same behavior.

@gabrielschulhof With regards to the configuration, I cannot embed it for two reasons:

• I am willing to provide a single set of binaries for all the configurations (this is the reason why I am willing to upgrade to N-API)
• For debugging purposes, the developer may need to tweak the configuration file

[gabrielschulhof]

@raffaeler from your description of the "functions queue" it sounds like exactly what the thread-safe function does.

May I ask how you provide the native addon? Do you provide it as an npm package? Given that you said you did not control the JavaScript that loads the addon it sounds like you're providing the binary only, and instructing your users to place the configuration file into the same directory as the binary.

If this is the case, would it be possible to instruct your users to henceforth place the configuration file in a different location? The reason I ask is that with libuv you are able to retrieve the user's home directory using uv_os_homedir() and so you could assemble a file name like ${HOME}/.my-module.conf by also examining process.platform to establish the path separator:

  size_t os_homedir_length = 1;
  char one_byte;
  char* os_homedir = nullptr;
  int result = uv_os_homedir(&one_byte, &os_homedir_length);
  os_homedir = new char[os_homedir_length];
  result = uv_os_homedir(os_homedir, &os_homedir_length);
  assert(result == 0);

  std::string platform = env.Global()
    .Get("process").As<Napi::Object>()
    .Get("platform").As<Napi::String>();

  char path_sep = platform.compare("win32") == 0 ? '\\' : '/';

  std::string config_file_path =
      std::string(os_homedir) + path_sep + ".my-module.conf";

  delete[] os_homedir;

  // Now you can use config_file_path

[raffaeler]

@gabrielschulhof thanks for the answer. I will investigate the threading function as soon as I solve the more basic problems.

Yes, the addon is provided via npm but since it can be used in multiple apps, it would not be wise to use the user's home directory. The configuration file must be kept app-specific.
The user may change the config file to add more "probing paths" that the CLR can load when dynamically loading the user's dlls. There are also logging settings and mappings used for the marshalling strategies. All these settings (and others) are definitely different from app to app.

It looks very strange not to have the ability to know where the addon binary is currently stored. I really don't get the reason for this decision.

[gabrielschulhof]

@raffaeler if the addon is provided via npm and consumed by the various applications as require('package-name') then it should always be possible to interject an index.js which then loads the addon using the ping-pong method I described earlier.

Each app that uses the addon would then install its own copy with its own config file. If the package is installed globally using npm install -g then it's not possible to have one config file for each app, even if module were available.

[raffaeler]

@gabrielschulhof If the user decides to install it globally, I (and the user) expect the settings are shared too (which is fine if this is what the user wants).
There are many packages that are suggested not to be installed globally, and this is one of them.

With regards to the index.js, it is an additional step just to receive the module information, which is something that existed before N-API ... isn't this a clear sign of a missing/forgot feature?
The native addons should have parity of features, or at least this is what the docs say.
I want to avoid js files which requires more explanations to the user as well as the .ts definitions.

Instead of adding a js file, I will probably end up in taking the project root folder (process.mainModule) and scan all the directories but this is a terrible and slow solution.

[mhdawson]

I wanted to understand what was needed from the module directory and why they are needed. From what I parse from the discussion the main gap is the ability to get the path for the module.

@gabrielschulhof we should be able to grab the path as part of the module creation and potentially stash in the env, then expose through something like napi_get_addon_path. @gabrielschulhof does that sound reasonable to you or are there problems/concerns that you can think of? @raffaeler even if we do that it may only be for the latest node versions so might only be a longer term solution.