Importing in electron, ts, webpack app comes back as undefined

[samlhuillier]

When I try to do this in my electron app:
import { LlamaModel, LlamaContext, LlamaChatSession } from "node-llama-cpp";

console.log(LlamaModel);
console.log(LlamaContext);
console.log(LlamaChatSession);

I get back each of them being undefined. Anyone know how to fix?

[samlhuillier]

Looks like this works:
require("node-llama-cpp").then((nodeLLamaCpp: any) => {
const model = new nodeLLamaCpp.LlamaModel({

Closing discussion :)

[giladgd]

@v4lentin1879 This limitation seems to be imposed by VS Code Loder as it runs each extension in an isolated environment using node's vm module without setting importModuleDynamically, which makes it impossible to load ESM modules.

Due to the nature of how node-llama-cpp works, the structure of the files of the module must be preserved in order for it to work properly, so it'd have to be packed into the VS Code extension in its original structure, and using a bundler to bundle all of its code into one file cannot be done as it would break it (you should mark node-llama-cpp as an external module in your bundler of choice).

IMO, the best way forward for this is to add support for importing ESM modules in extensions in the VS Code loader.

I've looked at the code of VS Code Loader a bit, and it seems that creating a PR for this shouldn't be too complicated.
There are 4 usages of node's vm Script there, and each of them should be supplied with an added importModuleDynamically in the options, to supply the logic that will actually make the dynamic import work on the Electron side, and the resolving of the module to import should be done relatively to the script file path (to make sure the requested module/file is resolved from the node_modules folder of the extension and not from VS Code's node_modules folder for example).

It's important to detect whether the current code is running in the main process or the renderer process, as using a dynamic import of a node module on the renderer can crash the process (from my experience with it).
Since extensions are supposed to be loaded on the main process, this shouldn't be an obstacle, but it's important to handle that case.

I would have done this myself, but I'm not sure I'll have enough time for this soon, since I'm currently working on preparing node-llama-cpp's beta version for a stable release, and it's taking all of my time.

[v4lentin1879]

@giladgd Thank you so much! I will look into this and raise a pr then.. 😁

[v4lentin1879]

@giladgd Another idea: Do you think it would be possible to fork node-llama-cpp and change it to use CommonJS?

[giladgd]

@v4lentin1879 node-llama-cpp depends on some modules that are also ESM-only, so doing that would require rewriting a lot of the code to work with modules that support CommonJS.
Since the structure of the files is necessary for node-llama-cpp to function properly, bundling node-llama-cpp in its current form with its dependencies via CommonJS is impractical as it will break it.
Also, node-llama-cpp uses many features available only on ESM that cannot be replicated in a stable manner in CommonJS (such as top-level await, partial circular dependency graphs (due to TypeScript type guards), etc.).

Since the node ecosystem is moving to ESM, maintaining a new CommonJS module today is inadvisable.
Thus, I reckon it's inevitable that VS Code will have to support ESM to continue being compatible with the node ecosystem.

[v4lentin1879]

I understand. Thank you very much for explaining! :)