Skip to content

doc: document process.moduleLoadList #61276

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
Xstoudi wants to merge 3 commits into from
Closed

doc: document process.moduleLoadList #61276

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b061243
doc: document process.moduleLoadList
Xstoudi Jan 4, 2026
635af17
wrong terminology
Xstoudi Jan 5, 2026
1080338
expose and document loadedModules instead of moduleLoadList
Xstoudi Jan 9, 2026
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
25 changes: 25 additions & 0 deletions doc/api/process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2858,6 +2858,31 @@ console.log(memoryUsage.rss());
// 35655680
```

## `process.moduleLoadList`

<!-- YAML
added: v0.5.3
-->

* Type: {string\[]}

The `process.moduleLoadList` property returns an array of internal bindings and core modules that
Copy link
Contributor

@Hardanish-Singh Hardanish-Singh Jan 6, 2026

Choose a reason for hiding this comment

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

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);

were loaded during the current Node.js process execution.
Copy link
Contributor

@Hardanish-Singh Hardanish-Singh Jan 6, 2026

Choose a reason for hiding this comment

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

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.


```mjs
import { moduleLoadList } from 'node:process';

console.log(moduleLoadList);
// ['Internal Binding builtins', 'Internal Binding module_wrap', 'Internal Binding errors', ...]
Copy link
Member

@joyeecheung joyeecheung Jan 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

@Xstoudi Xstoudi Jan 7, 2026

Choose a reason for hiding this comment

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

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?

Copy link
Contributor Author

@Xstoudi Xstoudi Jan 7, 2026

Choose a reason for hiding this comment

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

Third option: leave is as is, untouched and undocumented on purpose.

Copy link
Member

@Renegade334 Renegade334 Jan 8, 2026

Choose a reason for hiding this comment

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

cc @aduh95 (#41233 (comment)) – don't know whether you still have an opinion?

Copy link
Member

@joyeecheung joyeecheung Jan 8, 2026

Choose a reason for hiding this comment

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

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.

Copy link
Member

@joyeecheung joyeecheung Jan 8, 2026

Choose a reason for hiding this comment

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

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

```

```cjs
const { moduleLoadList } = require('node:process');

console.log(moduleLoadList);
// ['Internal Binding builtins', 'Internal Binding module_wrap', 'Internal Binding errors', ...]
```

## `process.nextTick(callback[, ...args])`

<!-- YAML
Expand Down
Loading