-
Notifications
You must be signed in to change notification settings - Fork 29.1k
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
no way to programmatically discover node:test
#42785
Comments
cc @nodejs/modules @cjihrig @nodejs/test_runner |
|
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 |
@ljharb there's a workaround, but it requires to use '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:
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. |
I would prefer option 1, it seems acceptable as an opaque string. |
Option 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. |
I'm also in favor of option 1 (only because option 2 is off the table). |
An option 4 would be to freeze and expose the |
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 |
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. |
That's probably fine for the test runner, but I suspect it will be pretty limiting if future modules are added prefix-only. I guess I'll wait until that happens to bring it up again tho. |
@aduh95 this issue is not fixed; isBuiltIn doesn’t do it because you can’t discover node:test with it. Please reopen. |
@ljharb do we see a need for |
@hemanth possibly, but that still wouldn't address this issue either. We likely need an API that provides an iterator over all of the names of builtin modules ( |
@ljharb trying to recall on why we didn't ended up populating |
Probably because the assumption was that there'd never be a prefix-only module, but |
Hmm, need to verify if there are any side effects of populating |
All of the Should I do a PR if there are no other concerns? //cc @nodejs/modules |
PR-URL: nodejs/node#43396 Fixes: nodejs/node#42785 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com> Reviewed-By: Juan José Arboleda <soyjuanarbol@gmail.com>
> nodeModule.isBuiltin('node:test')
true After
|
## Description - ensures `node:test` is detected as a core module ## Motivation and Context Currently `node:test` dependencies are classified as unable to resolve. This is because `node:test` or `test` are not listed as `builtinModules` in node's `module` module. From the discussion on nodejs/node#42785 I understand this is never going to happen either. Alternative is to use `module`'s `isBuiltin()` function, but that is not available in the lowest version of nodejs dependency-cruiser supports (16.14), so we have to work around that. Additionally the `node:test` module can _only_ be required via the `node:` protocol (`const { test} = require('test')`/ `import { test } from 'test'` don't work). This means that with the current the way we split the protocol from the module name, using `isBuiltin` won't work either... ## How Has This Been Tested? - [x] green ci - [x] additional automated tests ## Types of changes - [x] Bug fix (non-breaking change which fixes an issue) - [ ] Documentation only change - [ ] Refactor (non-breaking change which fixes an issue without changing functionality) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) ## Checklist - [x] 📖 - My change doesn't require a documentation update, or ... - it _does_ and I have updated it - [x] ⚖️ - The contribution will be subject to [The MIT license](https://github.com/sverweij/dependency-cruiser/blob/main/LICENSE), and I'm OK with that. - The contribution is my own original work. - I am ok with the stuff in [**CONTRIBUTING.md**](https://github.com/sverweij/dependency-cruiser/blob/main/.github/CONTRIBUTING.md).
This issue also masks the existence of |
And it's likely that more will follow. For my 2 cents, the most logical approach IMO is to populate the |
Version
18.0.0
Platform
No response
Subsystem
No response
What steps will reproduce the bug?
require('module').builtinModules
How 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:test
is not listed.Additional information
There needs to be a way to programmatically discover all builtin modules.
require('module').builtinModules
is 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:test
wasn't part of is-core-module, but by making it effectively "secret", my tests didn't know about it.The text was updated successfully, but these errors were encountered: