`fs/promises`

[brettz9]

Is the exclusion of fs/promises deliberate for some reason in excluding /?

Thanks!

[sindresorhus]

The promises part is a sub-module. I don't think it would be correct to include that in the list.

https://github.com/sindresorhus/is-builtin-module correctly handles it though.

[brettz9]

Ok, great, thanks!

[raythurnvoid]

@sindresorhus I understand it's a submodule but node's "module" actually exposes it.
It's nice to have modules starting with "_" or internals omitted but i'm not sure is right to exclude whatever have a "/".
To give more context, Vite actually uses this during code transformation to check whatever a module imported by the user is a built-in and this is causing peoples to get errors stating that fs/promises is not a valid module.
Someone is workarounding it with import { promises as fs } from "fs".

I know that Vite could just use https://github.com/sindresorhus/is-builtin-module to fix this but it wouldn't be right because this may cause false positives eg: import { fs } from "fs/invalid" will pass as a built-in and the user would get an error only at runtime.

sveltejs/kit#1689 vitejs/vite#4037

[sindresorhus]

Ok. I didn't realize the import {builtinModules} from 'module'; exposed sub-modules too. Then this package should do the same.

[jimmywarting]

Hmm, i think is-builtin-module should be more advertised...

I guess most just don't care about what module there is... I guess all they really care about is wether or not it's a builtin or not and switch the logic of doing some npm vs node coding auto/refactoring. That's what is-builtin-module is doing... handling sub modules and node: protocols,

A big attention at the top that says "You probably don't want to depend on this directly if you only want to check if something is a builtin module, use is-builtin-module instead, it handles node: protocol and sub modules like fs/promises"