Skip to content

Conversation

@addaleax
Copy link
Member

@addaleax addaleax commented Aug 8, 2017

Add napi_get_node_version, to help with feature-detecting Node.js as an environment.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

N-API

/cc @nodejs/n-api

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Aug 8, 2017
@addaleax addaleax added node-api Issues and PRs related to the Node-API. semver-minor PRs that contain new features and should be released in the next minor version. and removed lib / src Issues and PRs related to general changes in the lib or src directory. labels Aug 8, 2017
doc/api/n-api.md Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Period after Optional and after process.release.name.

src/node_api.cc Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a test where release is null.

src/node_api.cc Outdated
Copy link
Contributor

@kfarnung kfarnung Aug 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a string out parameter is a little bit risky since there needs to be a clear chain of ownership. In this case it will always be a constant string, but as a developer it may not be clear what the scope of the string is and whether it needs to be freed by the caller.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but as a developer it may not be clear what the scope of the string is and whether it needs to be freed by the caller.

I can add a bit to the docs if you have a suggestion for wording, but since this refers to a const char pointer, there isn’t really any ambiguity.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @addaleax, you're right about the const char * being a good indicator, I hadn't really considered that the object would not be a valid argument to free with the const modifier. It does seem like all usages of this function would at least yield a global string value, so I think my original concern is invalid. I'll take a look at the documentation and suggest any specific changes there.

src/node_api.cc Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to use a struct here? I see two benefits:

  • No need for the developer to study the documentation to determine the size of the array required
  • Easier to access the parts of the version by member name

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, that makes sense. I’ll push again in a couple minutes.

@addaleax addaleax force-pushed the napi-node-version branch from b41455a to b2e5ccf Compare August 8, 2017 18:25
@addaleax
Copy link
Member Author

addaleax commented Aug 8, 2017

@kfarnung I’ve updated this anyway with the struct approach and clarified that the returned buffer is statically allocated, please take a look :)

src/node_api.cc Outdated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're returning a pointer to this static struct, should the result be a const napi_node_version** to prevent modification by the callers?

I think the other option would be to use a single indirection to a non-const napi_node_version and then just fill in the values. I'm fine either way.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're returning a pointer to this static struct, should the result be a const napi_node_version** to prevent modification by the callers?

Yes. :)

I think the other option would be to use a single indirection to a non-const napi_node_version and then just fill in the values. I'm fine either way.

I thought about that, but this approach has the advantage of being extensible on the N-API side in a backwards-compatible fashion, if we or somebody else (Node forkers?) ever need to do that.

Copy link
Contributor

@kfarnung kfarnung Aug 8, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on the current approach.

Copy link
Contributor

@kfarnung kfarnung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@bnoordhuis
Copy link
Member

FWIW, libuv has two separate functions for this, one that returns a version string and one that returns major * 65536 + minor * 256 + patch. Seems simpler than having an out pointer arg.

Aside: the env argument isn't (meaningfully) used. Maybe remove it?

@jasongin
Copy link
Member

jasongin commented Aug 8, 2017

the env argument isn't (meaningfully) used. Maybe remove it?

All the napi_* functions have a env parameter, even though a few of them don't currently use it. We do this for a few reasons:

  1. Consistency
  2. N-API implementation on other VMs may require a context even if it isn't needed for V8.
  3. If/when node supports multiple environments/isolates in a process we will be able to update the implementation without having breaking changes.

Maybe for this particular case, items 2 and 3 will never be an issue. But still it would be strange if this API did not follow the pattern of all the others that have env as the first parameter.

@addaleax
Copy link
Member Author

CI: https://ci.nodejs.org/job/node-test-commit/11696/

This should be ready.

doc/api/n-api.md Outdated
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it make sense for this struct to also include the dependency version details equivalent to process.versions?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t like it when N-API exposes things that are already doable by just calling into JS, using, well N-API :) This particular function might be required to check whether some of that calling-into-JS works the way you want it to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, eventually one of the goals should be for Node.js itself to use N-API internally, in which case this method would be the way to get at this information from JS :-) .. but that's down the road.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, eventually one of the goals should be for Node.js itself to use N-API internally

I think N-API inherently adds too much complexity to fully replace the other APIs we use. :)

in which case this method would be the way to get at this information from JS

Adding new methods is easy, and this was implemented specifically in a way that’s easy to extend on the N-API side. :)

@addaleax
Copy link
Member Author

addaleax commented Aug 12, 2017

Add `napi_get_node_version`, to help with feature-detecting
Node.js as an environment.

PR-URL: nodejs#14696
Reviewed-By: Kyle Farnung <kfarnung@microsoft.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
@addaleax
Copy link
Member Author

Landed in 835c383

@addaleax addaleax closed this Aug 12, 2017
@addaleax addaleax deleted the napi-node-version branch August 12, 2017 19:29
addaleax added a commit that referenced this pull request Aug 12, 2017
Add `napi_get_node_version`, to help with feature-detecting
Node.js as an environment.

PR-URL: #14696
Reviewed-By: Kyle Farnung <kfarnung@microsoft.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
addaleax added a commit that referenced this pull request Aug 12, 2017
Add `napi_get_node_version`, to help with feature-detecting
Node.js as an environment.

PR-URL: #14696
Reviewed-By: Kyle Farnung <kfarnung@microsoft.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
@addaleax addaleax mentioned this pull request Aug 13, 2017
gabrielschulhof pushed a commit to gabrielschulhof/node that referenced this pull request Apr 10, 2018
Add `napi_get_node_version`, to help with feature-detecting
Node.js as an environment.

PR-URL: nodejs#14696
Reviewed-By: Kyle Farnung <kfarnung@microsoft.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
MylesBorins pushed a commit that referenced this pull request Apr 16, 2018
Add `napi_get_node_version`, to help with feature-detecting
Node.js as an environment.

Backport-PR-URL: #19447
PR-URL: #14696
Reviewed-By: Kyle Farnung <kfarnung@microsoft.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
@MylesBorins MylesBorins mentioned this pull request Apr 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

c++ Issues and PRs that require attention from people who are familiar with C++. node-api Issues and PRs related to the Node-API. semver-minor PRs that contain new features and should be released in the next minor version.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants