-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
[v14.x] node-api: allow retrieval of add-on file name #37327
[v14.x] node-api: allow retrieval of add-on file name #37327
Conversation
866dd16
to
dd3936e
Compare
The solution to the conflict in this backport backport consists of restoring the names of the macros used in the test: Whereas on the main branch it was
on this branch it is the old
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
11505ad
to
6b115d7
Compare
This conflicts with #37728 |
23ede20
to
f755fc4
Compare
dd3936e
to
6b6f28e
Compare
@targos rebased. |
@danielleadams rebased. |
49c8441
to
50b3bd0
Compare
1f06fcf
to
16dcd9c
Compare
8ea39c6
to
4ac719f
Compare
073941c
to
0061e5d
Compare
Unlike JS-only modules, native add-ons are always associated with a dynamic shared object from which they are loaded. Being able to retrieve its absolute path is important to native-only add-ons, i.e. add-ons that are not themselves being loaded from a JS-only module located in the same package as the native add-on itself. Currently, the file name is obtained at environment construction time from the JS `module.filename`. Nevertheless, the presence of `module` is not required, because the file name could also be passed in via a private property added onto `exports` from the `process.dlopen` binding. As an attempt at future-proofing, the file name is provided as a URL, i.e. prefixed with the `file://` protocol. Fixes: nodejs/node-addon-api#449 PR-URL: nodejs#37195 Co-authored-by: Michael Dawson <mdawson@devrus.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
6b6f28e
to
db14845
Compare
Landed in d98d193 |
Unlike JS-only modules, native add-ons are always associated with a dynamic shared object from which they are loaded. Being able to retrieve its absolute path is important to native-only add-ons, i.e. add-ons that are not themselves being loaded from a JS-only module located in the same package as the native add-on itself. Currently, the file name is obtained at environment construction time from the JS `module.filename`. Nevertheless, the presence of `module` is not required, because the file name could also be passed in via a private property added onto `exports` from the `process.dlopen` binding. As an attempt at future-proofing, the file name is provided as a URL, i.e. prefixed with the `file://` protocol. Fixes: nodejs/node-addon-api#449 PR-URL: #37195 Backport-PR-URL: #37327 Co-authored-by: Michael Dawson <mdawson@devrus.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
Unlike JS-only modules, native add-ons are always associated with a dynamic shared object from which they are loaded. Being able to retrieve its absolute path is important to native-only add-ons, i.e. add-ons that are not themselves being loaded from a JS-only module located in the same package as the native add-on itself. Currently, the file name is obtained at environment construction time from the JS `module.filename`. Nevertheless, the presence of `module` is not required, because the file name could also be passed in via a private property added onto `exports` from the `process.dlopen` binding. As an attempt at future-proofing, the file name is provided as a URL, i.e. prefixed with the `file://` protocol. Fixes: nodejs/node-addon-api#449 PR-URL: #37195 Backport-PR-URL: #37327 Co-authored-by: Michael Dawson <mdawson@devrus.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
Unlike JS-only modules, native add-ons are always associated with a dynamic shared object from which they are loaded. Being able to retrieve its absolute path is important to native-only add-ons, i.e. add-ons that are not themselves being loaded from a JS-only module located in the same package as the native add-on itself. Currently, the file name is obtained at environment construction time from the JS `module.filename`. Nevertheless, the presence of `module` is not required, because the file name could also be passed in via a private property added onto `exports` from the `process.dlopen` binding. As an attempt at future-proofing, the file name is provided as a URL, i.e. prefixed with the `file://` protocol. Fixes: nodejs/node-addon-api#449 PR-URL: #37195 Backport-PR-URL: #37327 Co-authored-by: Michael Dawson <mdawson@devrus.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
Unlike JS-only modules, native add-ons are always associated with a dynamic shared object from which they are loaded. Being able to retrieve its absolute path is important to native-only add-ons, i.e. add-ons that are not themselves being loaded from a JS-only module located in the same package as the native add-on itself. Currently, the file name is obtained at environment construction time from the JS `module.filename`. Nevertheless, the presence of `module` is not required, because the file name could also be passed in via a private property added onto `exports` from the `process.dlopen` binding. As an attempt at future-proofing, the file name is provided as a URL, i.e. prefixed with the `file://` protocol. Fixes: nodejs/node-addon-api#449 PR-URL: nodejs#37195 Backport-PR-URL: nodejs#37327 Co-authored-by: Michael Dawson <mdawson@devrus.com> Reviewed-By: Michael Dawson <midawson@redhat.com>
Unlike JS-only modules, native add-ons are always associated with a
dynamic shared object from which they are loaded. Being able to
retrieve its absolute path is important to native-only add-ons, i.e.
add-ons that are not themselves being loaded from a JS-only module
located in the same package as the native add-on itself.
Currently, the file name is obtained at environment construction time
from the JS
module.filename
. Nevertheless, the presence ofmodule
is not required, because the file name could also be passed in via a
private property added onto
exports
from theprocess.dlopen
binding.
As an attempt at future-proofing, the file name is provided as a URL,
i.e. prefixed with the
file://
protocol.Fixes: nodejs/node-addon-api#449
PR-URL: #37195
Co-authored-by: @mhdawson
Reviewed-By: @mhdawson