Remove native modules optional dependency

Some users might want to use this library but without UDS support. For those, installing a native module might be prohibitive. Native modules can make npm install much slower. Also their compilation can fail. For example, installing hot-shots on my machine (Node 14.7.0) results in the bug described here:

> unix-dgram@2.0.4 install /home/ether/Desktop/node_modules/unix-dgram
> node-gyp rebuild

make: Entering directory '/home/ether/Desktop/node_modules/unix-dgram/build'
  CXX(target) Release/obj.target/unix_dgram/src/unix_dgram.o
In file included from ../src/unix_dgram.cc:5:
../../nan/nan.h: In function ‘void Nan::AsyncQueueWorker(Nan::AsyncWorker*)’:
../../nan/nan.h:2294:62: warning: cast between incompatible function types from ‘void (*)(uv_work_t*)’ {aka ‘void (*)(uv_work_s*)’} to ‘uv_after_work_cb’ {aka ‘void (*)(uv_work_s*, int)’} [-Wcast-function-type]
 2294 |     , reinterpret_cast<uv_after_work_cb>(AsyncExecuteComplete)
      |                                                              ^
In file included from ../../nan/nan.h:56,
                 from ../src/unix_dgram.cc:5:
../src/unix_dgram.cc: At global scope:
/home/ether/.cache/node-gyp/14.7.0/include/node/node.h:746:43: warning: cast between incompatible function types from ‘void (*)(v8::Local<v8::Object>)’ to ‘node::addon_register_func’ {aka ‘void (*)(v8::Local<v8::Object>, v8::Local<v8::Value>, void*)’} [-Wcast-function-type]
  746 |       (node::addon_register_func) (regfunc),                          \
      |                                           ^
/home/ether/.cache/node-gyp/14.7.0/include/node/node.h:780:3: note: in expansion of macro ‘NODE_MODULE_X’
  780 |   NODE_MODULE_X(modname, regfunc, NULL, 0)  // NOLINT (readability/null_usage)
      |   ^~~~~~~~~~~~~
../src/unix_dgram.cc:404:1: note: in expansion of macro ‘NODE_MODULE’
  404 | NODE_MODULE(unix_dgram, Initialize)
      | ^~~~~~~~~~~
  SOLINK_MODULE(target) Release/obj.target/unix_dgram.node
  COPY Release/unix_dgram.node
make: Leaving directory '/home/ether/Desktop/node_modules/unix-dgram/build'

While there are solutions to the problem above, native modules tend to create problems like this.

Making them an optionalDependencies does not solve this. It only makes npm install succeed when the compilation fails, but it does not remove the time spent compiling. Unfortunately, npm does not have a way to disable specific optionalDependencies, it only has a way to disable all of them.

One way to provide UDS without forcing users into installing native module would be to create a second separate package with UDS support, which would use the same core logic as this package. What do you think?

[mariusandra]

I’ll second that this optional dependency is making me look for an alternative statsd client (for posthog-plugin-server). Our logs are cluttered with this gyp failure and it’s hard to parse them and see that actually everything is fine.

A clean approach out of this would be to pass the const socket = require('unix-dgram').createSocket().bind('/path') variable to hot-shots during init. For example as the hostname. That way whoever wants can require and use it outside…

[matej-prokop]

Sorry - now I see that my previous message was probably missleading.

During npm install npm always tries to install unix-dgram but that fails because gyp is missing in our environment. Entire npm install finishes because unix-dgram is optional dependency so npm ignores/skips this failure. So for instance build in CI is passing and everything is nicely green.

Nevertheless, actual problem is perception from user perspective (for user that did npm install in their development environment). That “failing” installation of unix-dgram produces huge error message into output (see attached screenshot below); therefore, user thinks that there is something really wrong or that it just failed completely. They ping you "there is something wrong with your package", you reply with "please ignore that error that's fine" and they say "ignoring errors is way to hell, please fix it" and you "sorry I can't". Now, imagine there are plenty of such users so rolling that out to all of them would cause avalanche of complains and pushback.