should this be isGeneratorFunction

isMap()

If a new deprecation is introduced, it should be recorded in doc/api/deprecations.md.

We no longer need this with isTypedArray being present in lib/internal/types.js.

Four-space indentation. Ditto elsewhere.

@TimothyGu All other macro lists I can find use 2 spaces for indentation?

Heh. Never mind then, I guess.

Maybe Array.isArray() as per our style guide note about parentheses after methods (+ below and in the bottom reference).

@vsemozhetbyt Yup, done!

util.types.isDate() seems undocumented.

@vsemozhetbyt Oops, thanks for catching this!

&& value !== null?

+ Is not typeof value can be either'object' or 'function'?

> const v = ()=>{}
undefined
> typeof v === 'object'
false
> typeof v
'function'

|| value === null ?

Would be good to have TypeError (and/or some other built-in Errors) here too.

Something that may be surprising to JavaScript developers unfamiliar with iterators is that the iterators returned from .keys(), .values(), .entries(), and [@@iterator]() in fact look the same from the outside. Maybe have them here as well would aid comprehension? (Ditto for Set.)

Alphabetically (what other API docs do), Uint16 would sort earlier than Uint8. This is certainly as good of a place for exception as any, but I'd like to keep it consistent for now.

The same for util.types.isInt8Array(value).

I do think this sorting order is a little less weird, tbh … 😄

Would new WebAssembly.Module(wasmBuffer) be a better example because of its synchronicity?

If this asynchronous example is to be kept, then it seems MDN spec it should be const module = rather than const { module } =.

If this asynchronous example is to be kept, then it seems MDN spec it should be const module = rather than const { module } =.

I don’t know why, but I don’t think V8 and MDN agree here.

Seems like you used compile here but instantiate in the test. Instantiate does indeed return { module, instance }.

This function is implemented as value !== null && typeof value === 'object'.

Maybe also mention that even though functions are also objects, isObject historically returned false even for functions, because it's broken.

The doc as-is doesn't make much sense.

s/string/symbol/

Also, no need for e.g. as Object() is the only way to get symbol objects in JavaScript (new Symbol() always throws an error).

Ditto as the documentation change. You could use WebAssembly.Module's constructor to avoid the async-ness. If not, we don't really need to instantiate it. WebAssembly.compile should be sufficient.

Yeah, I simply didn’t know you could just, you know, use new to construct a Module. ;)

Do we have an existing check for Generator objects? In any case, I am interested in seeing a reliable JS equivalent for isGeneratorObject.

@TimothyGu I’d guess you’d usually just check for presence of the methods? It’s not “reliable” in the sense that the V8 method is, but I didn’t see much benefit in including this, plus (and I could be completely wrong about that) I’d guess that this doesn’t work on transpiled generator functions anyway?

I’m happy to include it if you think it makes sense.

I’d guess you’d usually just check for presence of the methods?

Doesn't this kind of defeats the whole point of having these functions available?

I’d guess that this doesn’t work on transpiled generator functions anyway?

True, but this wouldn't be the first function that doesn't either.

I really like this test!

process.on('exit') wouldn't be necessary if the WebAssembly.Module is created synchronously.

Out of ABC-order?

Is --pending-deprecation the correct type here? It's the first such one, afaik.
DEP0005 is also a --pending-deprecation, but does not mention that explicitly.
/cc @jasnell, I suppose.

Also, --pending-deprecation (and it being a semver-minor) is not mentioned in COLLABORATOR_GUIDE.md#deprecations, but that's probably a separate issue.

As I understand, currently --pending-deprecation is just a subclass of doc-only deprecations.

I opened #18417 for that.

As I understand, currently --pending-deprecation is just a subclass of doc-only deprecations.

I’m okay with seeing it that way, yeah. And I don’t mind being explicit about this here.

#18433 landed, so could you change this line to

Type: Documentation-only (supports [`--pending-deprecation`][])

for consistency?

This should be util.types.isDate(new Date())

a async ->an async?

ArrayBuffer.isView -> ArrayBuffer.isView() (+ everywhere including bottom reference)?

Maybe const proxy = new Proxy(target, {}); to make target more target?)

The same for util.types.isInt8Array(value).

Should be after WeakMap.

Just noting that this will have a named-import-in-ESM issue just like the fs.promises addition.

We should likely note in the documentation how these checks are performed because types can lie about what they are if the user overrides Symbol.toStringTag.

This function is cached at Node.js startup and thus immune to userland overrides.

Ah right right... completely zoned on the caching. Just verified locally that even preload script can't lie about this. Dismiss this comment then :-)

Actually... @addaleax ... this would be something worth adding to the tests... specifically, ensuring that a user-provided class overriding a built-in set within a preload module cannot lie and that the checks will come up as false.

a user-provided class overriding a built-in set within a preload module cannot lie

I’m not sure what you mean by that. I have added a test that checks that overriding Symbol.toStringTag doesn’t fool this.

The test should also likely verify that the result is consistent across vm contexts... e.g. check that vm.runInNewContext('new Map()') passes the type check.

add:

util.types.isBooleanObject(Boolean(false)); // Returns false
util.types.isBooleanObject(Boolean(true)); // Returns false

Not sure if we should assert that it is 'built-in' in these. The objects can lie, and user code can create their own objects (polyfills) that are not actually built-ins.

async function here could be a link to more documentation about async functions... perhaps a link over the MDN documentation?

hmm... this last sentence is a bit content free. why would developers prefer to do type checking in JavaScript :-) ... I think it's better to say something about specific use cases such as "These are primarily useful for debugging" or something similar

@jasnell I can’t really agree … the “why” is, it’s a preference. I personally don’t think it’s a good idea, but it’s what Node decided to migrate to?

Saying “these are primarily useful for debugging” doesn’t really seem more helpful, because it doesn’t even say how you’d use these methods for debugging…

There's already https://github.com/nodejs/node/blob/master/test/parallel/test-types.js. You might want to look into combining these two files.

@TimothyGu I’ve just copied the contents into a block in this file, let me know if that doesn’t sound good to you. The tests have somewhat different structures, but I think that’s fine?