v2.0 API design

As discussed in #401, we are considering merging the webusb library into node-usb in order to take advantage of a standardised USB API - the WebUSB API specification.

I’d like to consider bringing in and merging the webusb library wholesale, however this comes with some drawbacks:

Device

• Potential loss of some of the lower-level usb details such as LIBUSB_* constants, extended descriptors, bus number, port numbers, kernel driver management, etc.
• Potential loss of endpoint polling
• WebUSB device loading would be heavier due to blocking functions needing to be called in order to build the device object. e.g. loading string descriptors.

My recommendation would be to adopt the WebUSB device as the shape of all USB device objects and consider unofficial extension points for features not supported above.

Discovery

• Potential loss of the simple getDeviceList() and findByIds() interfaces, instead using the slightly more complicated requestDevice().

This could be mitigated by exposing two device selection interfaces - WebUSB and Classic, both of which return WebUSB device objects.

In order to keep the API as simple as possible, I’m keen to understand which features can be deprecated and which must be kept. Can we get away with just using the WebUSB specification, or will this break common use cases (as I suspect).

To help with the new API design, any ideas and thoughts are welcome.

[thegecko]

I’ve implemented my proposal above and re-released v2.0.0 for feedback:

npm i usb@alpha

[thegecko]

@busticated I think that’s worth looking into. As binaries are currently created manually for some targets, I think the challenge will be how to automate usage of prebuildify in CI.

@koush You raise some interesting points. Removal of hotplug support will break backwards compatibility (and personally I’ve had issues with node-usb-detection on Windows as it doesn’t always discover serial numbers correctly). I’m hoping this will be implemented in libusb and plan to switch to the main fork at that point.

We are looking for a solid API to use for this library moving forwards and adopting the webusb API seems the most sensible approach.

FYI, progress towards this can be seen here which includes a lot of the changes already outlined:

https://github.com/thegecko/node-usb/tree/v2

Still very much a work in progress.