int*_*hab 21 javascript node.js
随着节点v4.0.0的发布.这个节点的版本弃用许多功能,如util.isArray,util.isRegEx,UTIL.isDate,util.isBoolean等等.
我想知道为什么这发生在节点上？
在ES6中是否有这些东西的原生支持？
或者节点是否提供了更好的解决方案而不是这些东西？
Tro*_*ott 31
util.is*()最初在Node.js技术指导委员会(TSC)上做出了弃用这些功能的决定.那时,它仍然是io.js,但同一个委员会现在是Node.js TSC他们谈论的代码库就是Node.js 4.0.0.
在从会议纪要是否在线.所以你可以自己阅读,看看权衡的利弊.在这几分钟内最明确的问题陈述可能来自Bert Belder:
我们想要弃用这些的原因是我们并不真的想要修复它,因为它会向后兼容,所以这实际上太大而不能用于核心.
(不幸的是,在几分钟内似乎有一些缺失的上下文.我会看看我是否可以从其他来源挖掘更多的上下文,如果我发现任何有用的内容,我会更新这个答案.)
更新:从2月份的一些TSC会议记录和同月的拉动请求讨论来看,似乎推理是这样的:
嘿,看起来像功能的util.isObject()回报false.这是不正确的.函数是一个对象.它应该回来true.但是,进行这种改变可能会破坏Node生态系统的很大一部分.想想npm上可能依赖于该行为的所有模块.为了不以惊人的方式冒险破坏生态系统,我们不得不以某种方式让很多人审查他们的代码.而突破性的变化将完全向后兼容.所有这些都是为了便利功能,它甚至不属于核心,并且易于由用户态模块提供.(例如,参见core-util-is.)不要仅仅为了修复而引入一个突破性的变化和一个半主要的冲击,而是util.isObject()让我们做首先应该做的事情,甚至不要在核心中进行.
我认为可能还有一种感觉,潜在的其他角落案例潜伏在这些util.is*()功能中.
一般而言,该项目的理念是拥有最小的核心.在所有条件相同的情况下,如果用户模块可以提供某些东西而不会有太多麻烦,它应该存在于用户空间模块而不是核心.
好吧,这是我从一些文本中得出了很多推论,但我认为这或多或少与弃用有关.