Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why have many util.is* functions been deprecated in node.js v4.0.0?

As node v4.0.0 has been released. This version of node deprecated many functions like util.isArray, util.isRegEx, util.isDate, util.isBoolean and many others.

I want to know why this happened to node?

Is there native support of these things in ES6?

Or does node provide any better solution instead of these things?

like image 552
intekhab Avatar asked Sep 11 '15 04:09

intekhab


People also ask

What is deprecated in node JS?

When the --throw-deprecation command-line flag is used, a Runtime deprecation will cause an error to be thrown. An End-of-Life deprecation is used when functionality is or will soon be removed from Node. js.

Is Nodejs 12 deprecated?

Following the release of Node. js 16 last week, Vercel is announcing the deprecation of Node. js 12, which reached its official end of life on April 30th 2022.

Is require deprecated in node JS?

It is not deprecated.

What is Nodejs Util?

The node. js "util" module provides some functions to print formatted strings as well as some 'utility' functions that are helpful for debugging purposes. Use require('util') to access these functions.


2 Answers

The decision to deprecate the util.is*() functions was initially made at a Node.js Technical Steering Committee (TSC) in April 2015. Well, at that point in time, it was still io.js, but the same committee is now the Node.js TSC and the code base they were talking about is what became Node.js 4.0.0.

The minutes from the meeting are online. So you can read it yourself to see the pros and cons that were weighed. The clearest statement of the issue in those minutes might be from Bert Belder:

The reason we want to deprecate these is that we don’t really want to fix it because that would be backward incompatible, so this is really too big to be in core.

(Unfortunately, there seems to be some missing context in the minutes. I'll see if I can dig up some more context from other sources and, if I find anything useful, I'll update this answer.)

UPDATE: Judging from some TSC minutes from February and discussion in a pull request from the same month, it seems like the reasoning is something like this:

Hey, looks like util.isObject() returns false for a function. That isn't correct. A function is an object. It should return true. But making that change potentially breaks huge portions of the Node ecosystem. Think of all those modules on npm that might be dependent on that behavior. In order to not risk breaking the ecosystem in surprising ways, we'd have to somehow get a ton of people to review their code. And the breaking change would be totally backwards incompatible. All for a convenience function that doesn't even really belong in core and is easily provided by userland modules. (See, for example, core-util-is.) Rather than introduce a breaking change and a semver major bump just to fix util.isObject(), let's do what should have been done in the first place and don't even have it in core.

I think there may have also been a sense that there were likely other corner cases lurking in the util.is*() functions.

The philosophy of the project in general is to have a minimal core. All things being equal, if something can be provided by userland modules without too much trouble, it ought to live in userland modules and not core.

OK, that's me drawing a lot of inferences from some bits of text, but I think that's more or less what's up with the deprecation.

like image 104
Trott Avatar answered Sep 28 '22 08:09

Trott


Not a node.js expert, but these functions (if they do what the name says) can be easily replaced by

[] instanceof Array; // true
/* or */ Array.isArray([]); // true

(/(?:)/g) instanceof RegExp; // true

new Date() instanceof Date; // true

new Boolean(true) instanceof Boolean; // true
/* or */ typeof false == 'boolean';
/* or even */ var bool1 = true, bool2 = false;
!!bool1 === bool1; // true
!!bool2 === bool2; // true

According to the changelog:

The util.is*() functions have been deprecated, beginning with deprecation warnings in the documentation for this release, users are encouraged to seek more robust alternatives in the npm registry.

They link this pull request that contains some of the reasoning which leads to this dialog, stating:

The reason we want to deprecate these is that we don’t really want to fix it because that would be backward incompatible, so this is really too big to be in core.

In short, these functions were buggy in some sense and instead of fixing the bugs and breaking backward compatibility, they decided to deprecate them instead.

If you really need to check these things often enough, you can write your own functions for that, if you wish.

like image 24
Sebastian Simon Avatar answered Sep 28 '22 08:09

Sebastian Simon