What to do with this project? Your opportunity for feedback and suggestions.

[cheery]

Hello everybody.

I think I've been overlooking the people using this library and I'm sorry about that one. I think it could be much better if I had responded to you properly. Although I've been listening people for a long while, it's been a scary place to give me feedback. That has changed now though.

This library has 3 dependents with documentation and 2 dependencies. I suppose it's not a popular or widely used library, and there may be already much better libraries out there. I wonder what should we do here?

I haven't been interested about node or udev for years, but apparently there are weird things happening. People are building statically typed languages that use Javascript as a platform, forming something similar to the link between typed-lambda calculus <--> untyped lambda calculus. I think this can be a good possible future for node/npm and whole Javascript ecosystem. The flaws are eventually resolved, and who knows if Javascript itself changes to better.

There are quite a few projects that depend on this library. Apparently one library uses it to detect mountpoints, another uses it to detect serial ports, third one uses to find usbled devices. These are clear I guess.

So let me know, what do you think should happen to this library? Is there a better library out there already? Any frustrations or issues you have had, or proposals to fix the issues?

I barely remember I made this library and I feel like it's just a wrapper anyway. What am I even doing maintaining this? But then, there are some upcoming projects that might be relevant here. I have a C-FFI header generator that I would like to renovate. This would provide easy FFI-headers for any possible language runtime you are interested about. It might be interesting to use it in this connection, as a testbed.

[AadamZ5]

Hi @cheery!

I think this library is a big convenience to have. One could live without this library using udev rules to run a hook script of some sort, but that approach is much more prone to issues and adds to complexity. This library can help alleviate that. It does have purpose!

Personally, I was looking to use this library for my own project. I am creating a hard-drive eraser, tester, and imager on a linux machine that needs to be able to detect new hard-drive inserts for hot-swap capability. My colleges and I will use this machine to deal with the large amount of hard-drives we have. I used a udev library in my python prototype, and it really cut out a significant amount of learning I had to do for the project. I didn't have to fuss with udev rules, no hook scripts or IPC, just a library that made it work.

I've decided to rewrite the prototype in NodeJS using TypeScript and am looking for a similar library, which I hope to see this fulfill that need. I hope this provides some insight, and yet another example of a use-case.

Let me know if you have any questions! Thanks!

[AadamZ5]

A quick question, why are you deciding to use the v8 and nan libraries instead of napi? I am new to C++ bindings in node, but from what I've found, N-API is much more compatible across version changes than the v8 and nan libraries alone.

[cheery]

I remember the move to NaN -library started from a contribution, otherwise I just used the things that were available back then. I don't remember researching much how it should be done, the first result and done. The N-API documentation looks neat and very clear. I noticed the build instructions that outright tell you how to build on different platforms. It could be worthwhile to make an N-API branch and see how it works for everybody if we moved to using N-API.

I'd guess you could use this library with Typescript seamlessly if we provide headers? Type information separates Typescript from Javascript, if I've understood that right.

Thank you for telling me that my library is a convenience. It used to be a part of a futile attempt to write a desktop environment for Raspberry Pi from scratch. Then it ended up drifting while I kept just checking that it stays fine.

Ok, this will be updated along the CFFI-project. It'll be a while before I get to doing it, but it's a project on my desktop. The first step is to look at the N-API. Anybody can try this out if they like. The important thing is to keep the API compatible for now.

To keep the API intact, we probably need to identify some type information for how the node-udev works right now.

[AadamZ5]

@cheery Sorry for the delayed reply, days can get busy and weeks can fly by!

I'm just getting into the N-API library, and want to use it more, and I am totally interested in contributing to this project using N-API. I have already cloned the repository and am going to work on making an N-API rewrite branch to see how well it works. I will take some time to do this since school and work steal my time, but I will make an effort to contribute.

You are correct about TypeScript. Type information is only for developing, and is separate of / non-existent in the actual JavaScript run time. After doing a rewrite with N-API and some more strictly separated code, I would love to provide typings in the library for the TypeScript devs. I suggest doing the types after the rewrite since the picture would be clearer as to what is actually being provided. Are you largely concerned about backwards compatibility?

Let me know if you have any ideas or concerns! Glad to hear from you.

[cheery]

I would gladly hear about what you like to change. There are very few users for this library and if we tell them nice what changed, update them on it and hear them out on changes as well, I'd guess they would understand.

I'm also curious about WebIDL, what do you think of this one? It's an interface description language used by web browsers.

[AadamZ5]

Well, I'm not exactly sure of any immediate change, I was just looking to establish how strict we needed to be with backwards compatibility.

I'm curious about WebIDL too, I've never heard of it before. I will have to read up on it to understand how you see it playing a part in the library. Maybe you could elaborate more on that once you get the chance. I urge you to make sure that even though it is targeted for web development, it is still useful for backend development. If that is solely a web technology for browsers, it may not be useful, but again, I am unfamiliar with it. Regardless, TypeScript typings are not hard to implement, and should still be added if you're looking to increase usability for TS devs :)

Hope that helps. Maybe a good place to start is a new branch for N-API?

[cheery]

Well, I would propose that we do an effort to keep things backward compatible, but lets allow the possibility to do changes. I think the good rule is: Think about how would you feel about the change if you were the user of this library.

WebIDL got wikipedia page that may help understand it better. It's a language they use to describe nearly every browser-provided Javascript interface there is. Few tools have been made:

• experimental tool for generating C++ - Js - N-API bindings, this seems the most promising so far, but I don't know how experimental is it?
• Emscripten got their own binder. I wonder if this is meant for interacting between emscripten and js, but I found so little in the first place.
• There's webidl-tools, but what it does is even harder to understand.

In any case this seems interesting. I'd guess the first one of those tools might be useful while the two last ones aren't too interesting to us. I've seen some Haskell libraries that parse WebIDL, btw. I could try those out some time. The curiosity of these tools is that mainly, we might be able to generate the big parts of these bindings.

We can just handwrite toward the N-API because it's probably not going to be big benefit to use the generators, but WebIDL might allow to specify the bindings in the same way they're specified elsewhere and that could be worthwhile.

Yup, I agree the new branch is in place, would you like me to start the new branch?

[AadamZ5]

Glad to see the new branch open!

When I get some downtime I will definitely make an effort to contribute. Just to prevent work overlap @cheery, are you planning to immediately do work on this right away? The idea I had was to just port the library "as-is" right now using N-API. Would you rather start from a blank slate? A direct port would give the quickest baseline iteration, but a total re-write could provide a cleaner code layout and possibly better functionality at the cost of longer first-iteration time.

[cheery]

@AadamZ5, "as-is" port is fine. I did look at the udev.cc code a bit. I think it's going to change quite a lot, but the code itself seems to be in a good structure that would still serve its use.

Btw. As I was exploring the repository, I used the blame -button and found out a detail that may be useful. The bulk of udev.js is a contribution and this commit explains what they are quite a lot. https://github.com/cheery/node-udev/pull/7

I won't touch this much any time soon. Most likely I will eventually see how npm modules have been documented to provide some documentation people would expect to find, once you're done. I also read up on what udev did and maybe extend the samples. I'll tell you about this in advance.