feat(util.is()): introduce

[AugustinMauroy]

Description

Close #116

[avivkeller]

@AugustinMauroy Can you check the original implementations and make sure these match them?

If they do, can you make that clear?

[AugustinMauroy]

@avivkeller & @ljharb I just applied what the docs said. So I will not change it for now.

Here docs ref

• DEP0044: util.isArray()
• DEP0045: util.isBoolean()
• DEP0046: util.isBuffer()
• DEP0047: util.isDate()
• DEP0048: util.isError()
• DEP0049: util.isFunction()
• DEP0050: util.isNull()
• DEP0051: util.isNullOrUndefined()
• DEP0052: util.isNumber()
• DEP0053: util.isObject()
• DEP0054: util.isPrimitive()
• DEP0055: util.isRegExp()
• DEP0056: util.isString()
• DEP0057: util.isSymbol()
• DEP0058: util.isUndefined()

[AugustinMauroy]

I'm sorry @ljharb but If you think there are better way to handle that please first update node api doc and then we will update this codemod

[ljharb]

For the opinion ones, fine, but one of them is a bug and is just broken. It shouldn't matter what's in the docs, but it matters what code does.

[AugustinMauroy]

For the opinion ones, fine, but one of them is a bug and is just broken. It shouldn't matter what's in the docs, but it matters what code does.

I'm annoyed because I'm caught between two stools. On the one hand, I agree with you. On the other, I want to follow the documentation strictly so that the org node is consistent.

[ljharb]

That seems like an arbitrary and counterproductive constraint to me. The docs aren’t the source of truth, they need to reflect the actual source of truth, the code.

[AugustinMauroy]

cc @ljharb synced with the pr

[ljharb]

LGTM, thanks!

[JakobJingleheimer]

Looking good!

Aside from a few small things / nets, I think it's just missing support for dynamic imports?

[AugustinMauroy]

I think it's just missing support for dynamic imports?

Any of our codemod support that so if we want to support that do it in aside pr that create utility + update codemod

[JakobJingleheimer]

Any of our codemod support that so if we want to support that do it in aside pr that create utility + update codemod

I think all of our migrations must support that in order to claim the deprecation is handled, which I believe is the intention. If it's best to create a shared util to do it, let's do that right away.

I thought you had previously said all of our current ones do handle this (and your message here also says they do, but I'm guessing from the rest that they actually don't?).

[AugustinMauroy]

think all of our migrations must support that in order to claim the deprecation is handled, which I believe is the intention. If it's best to create a shared util to do it, let's do that right away.

I just realized that we have utility for that but I was never used

I thought you had previously said all of our current ones do handle this (and your message here also says they do, but I'm guessing from the rest that they actually don't?).

It's a misunderstanding there are any of our codemod that support that