Skip to content

node-api: allow retrieval of add-on file name #37195

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.

Sign up for GitHub

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

Closed
gabrielschulhof wants to merge 5 commits into from
Closed

node-api: allow retrieval of add-on file name #37195

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
0f7da2c
node-api: allow retrieval of add-on file name
Feb 3, 2021
e2a7626
heed review comment
Feb 4, 2021
ecddc20
prefix with file://
Feb 7, 2021
77fff59
Update doc/api/n-api.md
Feb 8, 2021
2d017d4
retain message about null-termination
Feb 8, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
heed review comment
  • Loading branch information
Gabriel Schulhof committed Feb 7, 2021
commit e2a762656122ee484e3ee6c67fdcf2050d939b90
4 changes: 2 additions & 2 deletions doc/api/n-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5976,8 +5976,8 @@ node_api_get_module_file_name(napi_env env, const char** result);

* `[in] env`: The environment that the API is invoked under.
* `[out] result`: A null-terminated string containing the absolute path of the
Copy link
Copy Markdown
Member

@mhdawson mhdawson Feb 3, 2021

Choose a reason for hiding this comment

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

Is there any reason that it might be better to make this a URL versus restricting to a path. For example are there any ES6 cases where a module might be loaded from a URL versus a file on disk?

Copy link
Copy Markdown
Contributor Author

@gabrielschulhof gabrielschulhof Feb 4, 2021

Choose a reason for hiding this comment

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

For the sake of future-proofing I will change it to "the absolute path of the location from which the add-on was loaded."

Copy link
Copy Markdown
Contributor Author

@gabrielschulhof gabrielschulhof Feb 4, 2021

Choose a reason for hiding this comment

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

Done.

Copy link
Copy Markdown
Contributor Author

@gabrielschulhof gabrielschulhof Feb 4, 2021

Choose a reason for hiding this comment

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

I guess that doesn't make it a full-fledged URL, complete with file://. Did you have that in mind?

Copy link
Copy Markdown
Member

@mhdawson mhdawson Feb 4, 2021

Choose a reason for hiding this comment

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

I was thinking something like file:// to keep our options open. Not sure if there are any downsides?

Copy link
Copy Markdown
Contributor Author

@gabrielschulhof gabrielschulhof Feb 4, 2021

Choose a reason for hiding this comment

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

Aside from adding a little bit of parsing overhead, I can't think of any. I'll add that.

Copy link
Copy Markdown
Contributor Author

@gabrielschulhof gabrielschulhof Feb 4, 2021

Choose a reason for hiding this comment

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

Done.

file from which the add-on was loaded. The string is owned by `env` and must
not be modified or freed.
location from which the add-on was loaded. The string is owned by `env` and
must not be modified or freed.

`result` may be an empty string if the add-on loading process fails to establish
the add-on's file name during loading.
Expand Down