Repository navigation
no way to programmatically discover node:test #42785
Description
Activity
- added 2 commits that reference this issue
on Apr 19, 2022 import("node:test").then(()=>true, ()=>false)?That's not synchronous, and requires that I hardcode the identifier in advance.
I should be able to write code that works for all future prefix-only core modules without ever needing to hardcode their names.
@cjihrig ... Looking through the code it appears that not listing
node:testinbuiltinModuleswas intentional ... though it's not clear why. I agree with @ljharb that it likely should be there. Adding it, however, does break a handful of tests so I wanted to check to see what needs to be considered there first.Reacted by Jordan Harband@ljharb there's a workaround, but it requires to use
--expose-internals, sharing in case that unblocks you:'use strict'; const { internalBinding } = require('internal/test/binding'); const { moduleCategories: { canBeRequired }, } = internalBinding('native_module'); console.log(canBeRequired.has('test')); // true
@aduh95 thanks; good to know, but i don't think it suffices.
I think that the solutions here are either:
- add
node:testto builtinModules - make
testrequireable - add a new list of prefix-only core modules
My preference is the second one, the first is the simplest, and the third imo would be more of an argument for the second one because of the user confusion it furthers.
- add
I would prefer option 1, it seems acceptable as an opaque string.
Reacted by Ruben BridgewaterOption 2 has already been settled by the TSC vote. That makes options 1 and 3 the viable paths forward here. My preference would be for option 1. As far as I can tell, that shouldn't actually break anyone except a couple of our tests.
Reacted by Ruben BridgewaterI'm also in favor of option 1 (only because option 2 is off the table).
Reacted by Jordan HarbandAn option 4 would be to freeze and expose the
canBeRequiredset. I agree that option 1 and 3 are also viable paths, and option 1 is probably the simplest (although it might still be a breaking change?)I'm not sure why it would be - was it ever communicated that the API of this list is that nothing has a node prefix?
My tests were doing "builtinModule item", and "builtinModule item with a node prefix" - so i did have to change the logic to "only add the node prefix if it's not already there". That's a pretty minimal change tho, and arguably i shouldn't have hardcoded the assumption that things in that list don't have the prefix. So option 1 does seem like it'd be fine.
another oddity i noticed is that most all the builtin modules are available as globals in the repl - except for ones like
modulethat are shadowed by the CJSmodule- andtestis not available there. Should I file a separate issue for that? It seems like there'll be a bunch of unaccounted-for edge cases with the "prefix-only" approach the TSC vote unfortunately settled on.The repl limitation is known already. It's not worth opening an issue, I think. Prefix only modules just won't be available as globals in the repl.
20 remaining items
This issue also masks the existence of
node:seaandnode:sqlite.And it's likely that more will follow. For my 2 cents, the most logical approach IMO is to populate the
builtinModuleslist with all modules, each labeled with thenode:prefix (since havingnode:seaalongsidefs(notnode:fs) wouldn't make sense IMO).Reacted by Jordan Harband- added a commit that references this issue
on Dec 14, 2024 - added 2 commits that reference this issue
on Dec 18, 2024
Version
18.0.0
Platform
No response
Subsystem
No response
What steps will reproduce the bug?
require('module').builtinModulesHow often does it reproduce? Is there a required condition?
No response
What is the expected behavior?
Everything that's requireable that ships with node is listed (or, the listed items are requireable with
node:added).What do you see instead?
node:testis not listed.Additional information
There needs to be a way to programmatically discover all builtin modules.
require('module').builtinModulesis supposed to be it.This broke assumptions in my tests for https://npmjs.com/is-core-module - specifically, CIGTM should have failed prior to node 18 going out, because
node:testwasn't part of is-core-module, but by making it effectively "secret", my tests didn't know about it.