Feature Request: Add Node.js bindings.

[hwf1324]

I've recently been trying to create a VS Code extension, and I want to use the Hover API to output the content under the mouse cursor via Prism. This would allow for accessing the editor through the mouse.

[ethindp]

Hi there,

I am hesitant to introduce new bindings into the main source tree of Prism. For one, they make maintenance significantly more complicated, and they also complicate the build system (which itself is already complicated). I however make an exception where the bindings need to be tightly coupled to Prisms internals or are easier to just tie into what already exists; an example of this is the Godot extension, which although could be an external project, was easier to just link directly into the repository. Same thing for the Python bindings, which effectively mandated building inline.

I am always happy to accept new bindings and will add them to the README. They will just be unofficial and not supported by Prism upstream and people will need to go to the repository of the respective bindings for support/assistance/feature requests.

Is there a reason why you would not wish to perhaps become the maintainer of the Node.JS bindings but instead wish them to be upstreamed?

[hwf1324]

First of all, I should clarify that I am not very familiar with C++, Node.js, or CMake.

Based on what I've learned over the past few days, I believe there are currently two possible approaches.

The first is to use the Node API to build a native C++ addon, which requires compiling it alongside the source code. Theoretically, this has the lowest overhead.

A solution that might be suitable for this project is: https://github.com/nodejs/node-addon-api + https://github.com/cmake-js/cmake-js

The second option is to use FFI for cross-language function calls, similar to how the Python bindings are implemented. (A possible choice is: koffi)

I lean towards the first solution.

I'm not sure if I can complete this task myself; I had AI generate some code for me, but since I'm not very familiar with CMake at the moment, I haven't successfully run it yet.

It would be great if someone capable of completing this work could take it on.

[ethindp]

@hwf1324 I appreciate your explanation. I may consider hosting the bindings and linking it to the official ones like we do with Python and Godot, but I'm also hesitant to do it because of the maintenance it adds. I'll definitely have to think on this.

[hwf1324]

I have no objections to this; without tools to automatically build bindings, maintenance is indeed a significant burden.

However, perhaps we could also refer to this project: https://ashvardanian.com/posts/porting-cpp-library-to-ten-languages/

This goal seems very close to ours.

[ethindp]

@hwf1324 Indeed it does. The problem is implementing it. Prism's build system is already an incredibly complicated one, and so the most preferable thing to do, in other build systems provided by other languages, is to just shell out to CMake to do the heavy lifting and let the language-specific build system do it's language-specific things.

The most ideal case would be to somehow make prism.h the ground truth for everything and then to auto-generate the bindings somehow. Unfortunately this requires clang or similar and comes with it's own caveats. For example, Prism uses numerous compiler attributes to indicate a precondition that must be satisfied, or that a function allocates in such a way as to not alias any other pointer, or similar, and so we would need some way of translating these into the translation format somehow, assuming Clang even provides us with that information. I do know that SWIG can do this kind of binding, but SWIG is also incredibly slow and one aim of Prism is to never be the bottleneck in an application, because the bottleneck is whatever Prism is talking to, and not Prism itself.

I would appreciate any suggestions and would be happy to collaborate on this, and we could convert this issue into a more generalized "language bindings enhancement" kind of issue as well.

[hwf1324]

Unfortunately, I’m not familiar with low-level development. I’m afraid there’s nothing I can do about this.

This may need to be treated as a long-term task.

[ethindp]

I guess it really depends on how far we'd like to go between just making the language binding and automating the process