TypeScript Typings and Engine Version Conflict

First of all THANK YOU for converting to TypeScript. 👏 /cc: @hassankhan

With that in mind, I think that there is now a subtle dependency bug in the package.json declaration. Possibly even in the documentation/README.md.

The package.json declares the engines runtime to be anything after Node 4.3.2 (e.g., "node": ">=4.3.2"). This conflicts with the later Node.js typings dependency of "@types/node": "^12.6.8".

Simply put the major version and minor version tagged in the semver string of @types/node corresponds to Node’s version. For example, @types/node v8 and @types/node v12.

Such that if someone were to have a dependency on @types/node v10 and HAP-NodeJS v0.5.3 they would run into compilation errors about missing types.

Expand: Example with Errors

{
  ...
  "devDependencies": {
    "@types/node": "^10.17.9",
    "typescript": "^3.7.3"
  },
  "dependencies": {
    "hap-nodejs": "^0.5.3"
  }
}

node_modules/hap-nodejs/dist/lib/Camera.d.ts:2:10 - error TS2305: Module '"child_process"' has no exported member 'ChildProcessWithoutNullStreams'.

2 import { ChildProcessWithoutNullStreams } from 'child_process';
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/hap-nodejs/dist/lib/util/hkdf.d.ts:2:10 - error TS2305: Module '"crypto"' has no exported member 'BinaryLike'.

2 import { BinaryLike } from 'crypto';
           ~~~~~~~~~~

node_modules/hap-nodejs/dist/lib/util/uuid.d.ts:2:10 - error TS2305: Module '"crypto"' has no exported member 'BinaryLike'.

2 import { BinaryLike } from 'crypto';
           ~~~~~~~~~~

Suggestions

To fix these discrepancies there seem to be at least two solutions:

1. Roll back @types/node to the oldest supported LTS release and update the engines section of package.json to reflect accordingly. Note: At the time of this message is v8 though it’s end-of-life is ~20 days away so v10 might be better.

2. Leave the typing definition on v12 as it is the current LTS release and update the engines section of package.json to reflect accordingly.

No doubt there are other suggestions but these seem like the two most pragmatic ones to me. I’m happy to help make these changes. I just want to know what people are amenable to before I submit the changes.

[KhaosT]

Sorry about the lack of involvement 😅

I’m down bumping the node requirement to v10 since the library already don’t support most of linux distro bundled node anyway. The requirement for v4.x was there because that was a common version back when the last time major changes happened to this library. Node certainly released a lot of major versions since then 😉

Feel free to submit a PR and I’ll merge that 🙏

[RLovelett]

However I know that most people (running Pis with Raspbian stretch) have currently v8 installed(?). So at least it would be a good step to move to v8, away from v4.

I think that’s probably fair. As far as I can tell, Stretch comes with 4.8.2. Though if you enable stretch-backports you get 8.11.1. It’s interesting to me that Debian is going to support either of those two versions (v4 or v8) since Node itself is no longer providing patches or security to either. That would imply that Debian is going to do that on their own. I digress.

Rasbian does seem to be using Buster and that comes with 10.15.2. Not to mention NVM (which is what I use on Rasbian) so that you can basically get whatever version you want irrespective of the distribution.

I think my suggestion would be to move to v10. It is the oldest currently supported Node LTS version.