Skip to content
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

Closed
noseratio opened this issue Oct 24, 2018 · 6 comments
Closed

Unable to compile for node 10.12.0 #63

noseratio opened this issue Oct 24, 2018 · 6 comments

Comments

@noseratio
Copy link

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]

@RupW
Copy link

RupW commented Oct 24, 2018

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.

@Spown
Copy link

Spown commented Oct 29, 2021

why is this just closed? at least add

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

to the package.json

@RupW
Copy link

RupW commented Oct 29, 2021

@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.

@Spown
Copy link

Spown commented Oct 29, 2021

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.

@RupW
Copy link

RupW commented Oct 29, 2021

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.

@Spown
Copy link

Spown commented Oct 29, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants