Modules: fixed loading of the built-in "crypto" module.#1050
Merged
xeioex merged 3 commits intonginx:masterfrom Apr 23, 2026
Merged
Modules: fixed loading of the built-in "crypto" module.#1050xeioex merged 3 commits intonginx:masterfrom
xeioex merged 3 commits intonginx:masterfrom
Conversation
4aec16a to
7195af7
Compare
Contributor
|
QJS addon order (fetch_module <--> shared_dict_module) swap. Is it intentional? Neither test covers the QJS (qjs_import) path. Given the fix also adds qjs_crypto_module, a QJS-variant test (or a note explaining it's already covered elsewhere) would be reassuring. |
Contributor
Author
js_crypto.t passes for both engines. or what do you mean? |
Since 3185ce8 (0.9.7), njs_crypto_module has been registered conditionally in auto/modules under NJS_HAVE_OPENSSL. libnjs.a is built for the nginx module via nginx/config.make with "./configure --no-openssl ...", so libnjs.a's njs_modules[] no longer contains the crypto module. The nginx addon lists (njs_http_js_addon_modules[] and njs_stream_js_addon_modules[], plus the qjs variants) were not updated accordingly, making "import cr from 'crypto'" fail at nginx -t with ENOENT. Added &njs_crypto_module and &qjs_crypto_module to the shared addon list under the existing NJS_HAVE_OPENSSL guard, next to the webcrypto entries. While here, the near-identical addon arrays were factored into shared macros in a new header nginx/ngx_js_modules.h, so adding a future conditional addon needs a single edit instead of four. This closes nginx#1049 issue on Github.
7195af7 to
f8e88e6
Compare
Contributor
Author
I restored it back for consistency. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since 3185ce8 (0.9.7), njs_crypto_module has been registered
conditionally in auto/modules under NJS_HAVE_OPENSSL. libnjs.a is
built for the nginx module via nginx/config.make with
"./configure --no-openssl ...", so libnjs.a's njs_modules[] no
longer contains the crypto module. The nginx addon lists
(njs_http_js_addon_modules[] and njs_stream_js_addon_modules[],
plus the qjs variants) were not updated accordingly, making
"import cr from 'crypto'" fail at nginx -t with ENOENT.
Added &njs_crypto_module and &qjs_crypto_module to the shared addon
list under the existing NJS_HAVE_OPENSSL guard, next to the webcrypto
entries.
While here, the near-identical addon arrays were factored into
shared macros in a new header nginx/ngx_js_modules.h, so adding a
future conditional addon needs a single edit instead of four.
This closes #1049 issue on Github.