doc: document process.moduleLoadList#61276
Conversation
|
Review requested:
|
bcf2e77 to
984da23
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #61276 +/- ##
==========================================
- Coverage 88.53% 88.52% -0.02%
==========================================
Files 704 704
Lines 208759 208750 -9
Branches 40277 40279 +2
==========================================
- Hits 184825 184790 -35
- Misses 15934 15971 +37
+ Partials 8000 7989 -11
🚀 New features to boost your workflow:
|
|
I'm okay with the doc changes, but any changes to functionality should be in a separate PR, IMO |
process.moduleLoadList was provided as-is instead of a copy of it Refs: nodejs#41233 Refs: nodejs#61276
e3e19f1 to
3e1972e
Compare
process.moduleLoadList was added in the early days but never documented Fixes: nodejs#41233
ea0665b to
b061243
Compare
process.moduleLoadList was provided as-is instead of a copy of it Refs: nodejs#41233 Refs: nodejs#61276
process.moduleLoadList was provided as-is instead of a copy of it Refs: nodejs#41233 Refs: nodejs#61276
|
Doc change is here, code change moved to this draft: #61287 Sorry for the commit soup |
doc/api/process.md
Outdated
| import { moduleLoadList } from 'node:process'; | ||
|
|
||
| console.log(moduleLoadList); | ||
| // ['Internal Binding builtins', 'Internal Binding module_wrap', 'Internal Binding errors', ...] |
There was a problem hiding this comment.
I think the current shape of the API isn't very suitable to be a proper, public API - for example the types and the module names are mixed into a string, and there are no guarantees about when the types would change or what types there are; the names of the modules are also highly volatile and cannot be reliably depended on, and this might backfire if users start to claim changes to this array - removing/adding internal modules or their types - are supposed to be semver-major, just because this is a documented API.
IMO a documented version of this should either expose enum-like constants for types, and/or just filter out all the internals in the array.
There was a problem hiding this comment.
Thanks for the review!
I also feel like it would be better to have something like { type: 'INTERNAL' | 'BUILTIN', name: string } in this list instead of concatened strings albeit as far as I understand, it wouldn't fix the concern regarding the removing/adding of internal modules being claimed as major changes. Or am I mistaken here?
Filtering out the internals is also a good option: tests do not rely on them being present anyway. Could this list become as list of builtins name in the form of ['foo', 'bar', 'baz'] instead of ['Internal Binding builtins', 'Internal Binding module_wrap', 'NativeModule foo', 'NativeModule bar', 'NativeModule baz'] ?
What's option seems the safest to you regarding the concerns you mentionned?
There was a problem hiding this comment.
Third option: leave is as is, untouched and undocumented on purpose.
There was a problem hiding this comment.
cc @aduh95 (#41233 (comment)) – don't know whether you still have an opinion?
There was a problem hiding this comment.
FWIW it wasn't added in #24775, as suggested in the changelog in this PR this dates back to the 0.x days when everything got exposed on process without a lot of thoughts into what's public and what's internal.
There was a problem hiding this comment.
Also I think my personal preference would be: a separate list of strings with public modules only, and document that instead > leave it as is > a separate list of objects with enum + names (including internals) > document the current API
| * Type: {string\[]} | ||
|
|
||
| The `process.moduleLoadList` property returns an array of internal bindings and core modules that | ||
| were loaded during the current Node.js process execution. |
There was a problem hiding this comment.
Small wording nit: "process execution" feels slightly redundant. "during the current process" might be cleaner.
- that were loaded during the current Node.js process execution.
- that were loaded during the current process.
doc/api/process.md
Outdated
|
|
||
| * Type: {string\[]} | ||
|
|
||
| The `process.moduleLoadList` property returns an array of internal bindings and core modules that |
There was a problem hiding this comment.
Nit: Since the documentation text specifically refers to process.moduleLoadList, should the example use process.moduleLoadList directly instead of destructuring?
import process from 'node:process';
console.log(process.moduleLoadList);Add a new `process.loadedModules` property that returns an array of public core module names that have been loaded during the current Node.js process execution. This provides a cleaner, documented API for accessing loaded module information compared to the undocumented `process.moduleLoadList`. Fixes: nodejs#41233 Refs: nodejs#61276
Add a new `process.loadedModules` property that returns an array of public core module names that have been loaded during the current Node.js process execution. This provides a cleaner, documented API for accessing loaded module information compared to the undocumented `process.moduleLoadList`. Fixes: nodejs#41233 Refs: nodejs#61276
|
Closed in favor of #61330 |
Add a new `process.loadedModules` property that returns an array of public core module names that have been loaded during the current Node.js process execution. This provides a cleaner, documented API for accessing loaded module information compared to the undocumented `process.moduleLoadList`. Fixes: nodejs#41233 Refs: nodejs#61276
process.moduleLoadList was added in the early days but never documented
Fixes: #41233