Add patch for ffi-napi and ref-napi

[j1elo]

This is needed because the ffi-napi's native addon for Node is extracted by pkg to the host filesystem, thus any shared library file that is to be loaded must also be extracted.

Do not confuse the Node's badly named process.dlopen (which is already handled by pkg's bootstrap script, but is also useless for ffi-napi) with the actual dlopen function pointer that ffi-napi loads from the system's library API.

Fixes #1744

[j1elo]

Things this PR might be lacking, but I don't know internal project's "howto" in order to add adequately:

• An assets array? The ffi-napi package installs a node addon that is found in node_modules/ffi-napi/build/Release/ffi_bindings.node, so I'm not sure if this patch should include something like:

  assets: [
    "build/Release/ffi_bindings.node",
  ]
  

• A test in test/

  • Would test/test-79-npm/ffi-napi/ffi-napi.js be the correct place?
  • What would the contents of package.json be? I've checked a couple at random, and they all seem to just contain the line "private": true but no "dependencies" at all.

[robertsLando]

AFAIK patches can also contain assets so you can add them there. Check developer docs

Would test/test-79-npm/ffi-napi/ffi-napi.js be the correct place?

Yes

What would the contents of package.json be

You can add the dependencies that you prefer in package.json. There are some tests that already do that

[j1elo]

Ok so here's the thing: ffi-napi uses ref-napi as a dependency.

ffi-napi installs "node_modules/ffi-napi/build/Release/ffi_bindings.node", and ref-napi installs "node_modules/ref-napi/prebuilds/linux-x64/node.napi.node".

So to make it work properly, I'm thinking that an additional patch would be needed to add ref-napi's addon module to the assets.

[j1elo]

What would the contents of package.json be

You can add the dependencies that you prefer in package.json. There are some tests that already do that

So for example, would this be a good place to load some other dependency, such like Vosk (which is what I've used for my tests) and trying to load the libvosk.so file in the test? That would be a good way to verify that the ffi-napi patch is actually working with a real-world library file.

Or should other mechanism be used for testing? Is there a shared library that can be used instead?

[robertsLando]

So for example, would this be a good place to load some other dependency, such like Vosk (which is what I've used for my tests) and trying to load the libvosk.so file in the test? That would be a good way to verify that the ffi-napi patch is actually working with a real-world library file.

Yes

[j1elo]

Ok with the latest commits I've added a test for ffi-napi, and an additional patch for its dependency ref-napi, which also contains a native Node addon that should be included as asset.

[github-actions[bot]]

This pull-request is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this pull-request entirely you can add the no-stale label

[github-actions[bot]]

This pull-request is now closed due to inactivity, you can of course reopen or reference this pull-request if you see fit.