Add a module for build-rs scripts?

[JohnScience]

Hello, hardcoding napi version in Cargo.toml is not always convenient for local development. Instead, I would like to see a module for build scripts that would determine napi version from node -v call and node api version matrix.

What do you think about it?

[JohnScience]

I noticed that create-neon package does infer versions based on Node version. However, it's done only at the time of creation of a package.

[kjvalencik]

@JohnScience Can you describe your use case a bit more?

The Node-API version set with a config flag in a Neon addon is a minimum version and does not need to match exactly. For addons that support multiple versions of Node, it's generally best practice to pick the lowest version that supports all of the required Neon features. There's not much of a reason to go below Node-API 6 since it's supported by every LTS version of Node.

If you only need to support a single Node version that you control, you can use the napi-latest feature flag. That will never be newer than the latest version supported by the latest LTS of Node. It's currently set to Node-API 8, which is even supported by by 12.x.

Adding a build script adds considerable complexity. Neon used to have one, but, put we put in a lot of work to remove it since it was the source of a lot bugs.

Thanks!

[JohnScience]

I've been contracted for creation of a frontend for server hosting a supervised learning algorithm that identifies areas of lungs affected by COVID. As a Rust dev, I just wrote as WASM module for browser and everything worked fine. However, somewhere in the process it was identified that it would be very convenient to be able to select specific paths, not just file contents, and keep track of them. However, file picker API on the web offers only "fake paths" for security reasons. We decided to use Electron, which offered proper access to the filesystem and many other niceties, because it seemed to be quite mature and easy (and it was). Electron runs on Node.js and I'm considering the use of neon for implementation of functions that would run on the main process of Electron (the process that runs in the Node.js environment and not in the Chromium engine).

However, right now I seem to face some issues with permissions

and if I don't receive help in the official Discord server of Electron, for example in my thread of the help channel, or come up with the idea how to debug the build process, I might end up ditching the idea of using Rust for the functionality and use JavaScript instead.

Regarding the build script module, I meant a module with functionality for build scripts, so that the library user can decided whether they are fine with the hardcoded napi version or they're fine with working on the bleeding edge. I admit that it's generally a good idea to have the lowest requirements, yet it come at the cost of ease of implementation and it can make sense to use the available features and lower the requirements if necessary.

[kjvalencik]

and it can make sense to use the available features and lower the requirements if necessary
If any features that are only available on newer versions are being used, this will cause a compiler error. What should the user do in this case? Neon currently favors static checks on Node-API versions to keep things clear rather than dynamic checks where a module might not fail until sometime in the future.

The issue is screenshot seems like it's related to the electron packaging and not the addon itself. Might this be a VM with a shared directory or something else that that would cause the symlink to fail? The paths seem like it might be trying to create a symlink across mount points.

I can personally attest that Neon works great in Electron. I work on a large commercial app that has used Neon+Electron for years.