CatalystCode / windows-registry-node

Read and Write to the Windows registry in-process from Node.js. Easily set application file associations and other goodies.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Unable to compile for node 10.12.0

noseratio opened this issue · comments

Seeing a bunch of Nan::-related warnings, and this error:

.\node_modules\ffi\src\ffi.cc(125): error C2039: 'ForceSet': is not a member of 'v8::Object' [.\node_modules\ffi\build\ffi_bindings.vcxproj]

See pull request #62 which switches from ffi to ffi-napi to fix this.

For v9 at least you can also use the unreleased master ffi from github, i.e. dependency "ffi": "node-ffi/node-ffi". I can't remember if this works on v10 or not.

commented

why is this just closed? at least add

  "engines": {
    "node": "<10"
  }

to the package.json

@Spown but we already have open PRs that fix some of the problems (or did a few years at least), like the one I linked above. And your change would be admitting defeat.

Feel free to propose that as a PR if you want. We haven't had any interest from the maintainers for a long time though.

commented

And your change would be admitting defeat.

It's not like you (or whoever cares to maintain this module) are exactly winning, right now.

I just spent an hour trying to figure out why node-gyp doesn't compile. Also it's not like this flag in package.json blacklists the module from the ecosystem or anything. As long as the problem persists - it should be there to notify any node@>=10 user it's not functional in his setup. It would also give users, who can switch node versions on per-project basis that they have an option to make it work. And when it's been fixed for >=10 - one can remove it from package.json. Because right now if you are not specifically browsing closed issues here on GitHub - there is no way to tell it's not supported.

@RupW sorry if I may sound harsh, but this is how npm ecosystem works or at least how it should. And I am already trying to get node-regedit to work - it seems to be more not dead promising. So no PRs, sorry.

Then the node ecosystem needs a way of reporting that on npmjs.com without relying on the maintainers, because no-one's actively maintaining this package.

commented

no-one's actively maintaining this package.

well, there is your problem right here.

node ecosystem needs a way of reporting that

and how is the system supposed to determine that "that"? Do they need to employ staff for building and running unit tests on everything or maybe create a neural network doing that? It's the maintainers job to maintain the module and ensure it's compatibility. The registry only list's it. Just because npm introduced some flags in package.json's schema to make life easier for everyone doesn't mean they become responsible for everything. They are not Aplle.

Anyway, no need to be that defensive. What I meant with my original comment was "if someone can close the issue - he might as well add this line into package.json" (no need for a PR - it's not a functional code base change). But if there is no one left here to do even that - then the topic is exhausted.