feat: abstraction of ffi api libraries loading

[lowlighter]

Is your feature request related to a problem? Please describe.

The FFI API starting boilerplate feels like it could be abstracted in deno std lib to be more friendly.

I feel like the switch should be put under the carpet and users should just pass the lib without the extension and the underlying function automatically append the correct one. I know that extensions are conventions, but users who don't wish to use the most commons one could still fallback on the current solution.

Currently you need the following:

// Determine library extension based on
// your OS.
let libSuffix = "";
switch (Deno.build.os) {
  case "windows":
    libSuffix = "dll";
    break;
  case "darwin":
    libSuffix = "dylib";
    break;
  case "linux":
    libSuffix = "so";
    break;
}

const libName = `./libadd.${libSuffix}`;
// Open library and define exported symbols
const dylib = Deno.dlopen(libName, {
  "add": { parameters: ["isize", "isize"], result: "isize" },
});

Granted, it's a small incovenience of ~10 lines of code (which could be even less) but it'd be nice anyway.

Describe the solution you'd like

Something along:

import { load } from "https://deno.land/std/ffi/load.ts"
const dylib = load("./libadd", {
    "add": { parameters: ["isize", "isize"], result: "isize" },
});

Describe alternatives you've considered

Currently using the first solution

[littledivy]

On Windows, dynamic libraries generally don't have lib prefix. So it's add.dll.

Also, This is useful but its not enough for most libraries that need to release libraries and cache them on first run. Currently, deno_bindgen use x/plug for that - maybe we could have something similar to x/plug in deno_std.

Note that x/plug is not complete too, it lacks support for loading aarch64-darwin libraries.

[lino-levan]

For anyone reading this thread in the future, x/plug does now support loading aarch64-darwin libraries since version 0.5.2

As for this specific issue, I don't really see this as something std should do, given that x/plug does already exist. Would love to get an opinion from someone on the core team though.

[iuioiua]

For anyone reading this thread in the future, x/plug does now support loading aarch64-darwin libraries since version 0.5.2

As for this specific issue, I don't really see this as something std should do, given that x/plug does already exist. Would love to get an opinion from someone on the core team though.

I'm happy to close this issue then if that's the case. WDYT, @kt3k?

[kt3k]

I'd like to hear the opinion from @aapoalas

[lino-levan]

Definitely would be good to hear some thoughts from Aapo. I should note that /x/plug hit 1.0 and is considered stable by the maintainers afaik.

[aapoalas]

My apologies, I had somehow missed the ping here.

I do concur with the above comments in the abstract: plug exists and it doesn't seem like a particularly necessary thing to duplicate it.

On the other hand, I've come to the conclusion that I myself am not comfortable running any 3rd party code alongside FFI permissions and thus any and all FFI related "required" convenience code can either only be locally duplicated or used from deno_std if it exists there. In this sense implementing this helper in std would make sense.

But, I am currently trying to pursue FFI API stabilisation and one of the things being looked at within that is loading of libraries. It might be that it becomes more interconnected with the module graph in which case this helper would need to change.

Another thing is my proposal/PR for FFI tokens which would enable FFI permission path gating among other things. That might make FFI restricted enough to reasonably allow running 3rd party code that does DLL loading like plug. Though plug is really quite dangerous (again in the abstract): It is trusted to download, save, and load a DLL for the user. A malicious actor could do this and load a secondary library alongside the first that is used to do whatever it wants.

From a security perspective it is a good idea to consider this in std. I'd say let's leave this open for now and look back at it once the FFI stabilisation moves forwards (or backwards).

[kt3k]

Note: @aapoalas's proposal is discussed here: denoland/deno#19099

I generally agree with the above. Let's keep this open and revisit when stabilization or token proposal made any progress