-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to compile for node 10.12.0 #63
Comments
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 |
why is this just closed? at least add "engines": {
"node": "<10"
} to the |
@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. |
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 |
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. |
well, there is your problem right here.
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. |
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]
The text was updated successfully, but these errors were encountered: