捍卫者usb管理控制系统

by Mike Groseclose

通过Mike Groseclose

捍卫超模块化JavaScript (In Defense of Hyper Modular JavaScript)

Last week npmgate was a big topic for the JavaScript community. For those of you who haven’t been following what happened, here’s the TL;DR:

上周，npmgate对JavaScript社区来说是一个大话题。 对于那些没有关注发生的事情的人，这里是TL; DR：

A company, named Kik, asked Azer Koçulu to give them the kik project name on npm. Azer said no (because he was already using it). Kik asked again, this time threatening to get lawyers involved for Trademark infringement. Azer forcefully said no and Kik escalated to npm. npm sided with Kik and moved ownership of the module away from Azer. In response Azer wrote I’ve Just Liberated My Modules and removed all of his packages from npm. One of the packages he removed was left-pad.

一家名为Kik的公司要求AzerKoçulu在npm上给他们命名kik项目。 Azer说不(因为他已经在使用它)。 Kik再次询问，这次威胁要让律师参与商标侵权。 Azer坚决拒绝，Kik升级为npm。 npm支持Kik，并将该模块的所有权移交给Azer。 作为回应，Azer写了《 我刚刚解放了我的模块》，并从npm中删除了他的所有软件包。 他卸下的一个包裹是左垫 。

The removal of left-pad from npm essentially broke the install process for any project using it as a dependency. The impact of this was large as it was being used by a large number of very popular projects (Babel, Atom, and React to name a few).

从npm中删除左键盘本质上破坏了任何使用它作为依赖项的项目的安装过程。 它的影响是巨大的，因为它被许多非常受欢迎的项目(Babel，Atom和React等)使用。

The Internet caught on fire ?.

互联网着火了。

This all caused a number of questions to be raised, most of which can be categorized by the following:

所有这些都引发了许多问题，其中大多数可以按以下类别进行分类：

1. Was this a trademark infringement? A legal issue.
   这是商标侵权吗？ 一个法律问题。
2. Should npm have sided with Kik? A business issue.
   npm应该支持Kik吗？ 业务问题。
3. Should you be able to un-publish a module that is a dependency of another module? A technical concern.
   您是否应该能够取消发布依赖于另一个模块的模块？ 技术上的关注。
4. Should npm modules be mutable? A technical concern.
   npm模块应该可变吗？ 技术上的关注。
5. Should the community use modules like left-pad as dependencies to begin with? A much larger discussion.
   社区是否应该使用像左键盘这样的模块作为依赖项开始？ 更大的讨论。

npm, and their legal team, will be the ones that ultimately need to figure out the business and legal issues (#1 & #2 above). It will be up to them to determine if this was truly was a trademark infringement and what the policy on requests like this will be going forward.

npm及其法律团队将是最终需要弄清业务和法律问题的人员(上述第一名和第二名)。 由他们来确定这是否确实是商标侵权，以及将对此类请求采取什么样的政策。

For #3 above (the ability to un-publish a module that is a dependency of another published module) npm has made the following statement:

对于上面的＃3(取消发布作为另一个发布模块的依赖项的模块的能力)，npm做出了以下声明：

npm needs safeguards to keep anyone from causing so much disruption. If these had been in place yesterday, this post-mortem wouldn’t be necessary.

npm需要采取保护措施，以防止任何人造成如此多的破坏。 如果这些在昨天已经到位，则无需进行验尸。

- @izs from kik, left-pad, and npm

-来自ikk ，左键盘和npm的@izs

Although npm-shrinkwrap can help with some of the mutability issues (#4), the only real mitigation I have seen is to bundle your dependancies with your published package. Rich Harris explains this in his article How to not break the internet with this one weird trick.

尽管npm-shrinkwrap可以解决某些可变性问题(＃4)，但我看到的唯一真正的缓解方法是将您的依赖关系与发布的软件包捆绑在一起。 里奇·哈里斯(Rich Harris)在他的文章“ 如何用这种奇怪的技巧不破坏互联网”中对此进行了解释。

So that leads us to #6, the reason this article exists:

因此，我们进入了第六条，这是本文存在的原因：

社区是否应该使用像左键盘这样的模块作为依赖项开始？ (Should the community use modules like left-pad as dependencies to begin with?)

In order to understand why this is even a debate, we should first understand left-pad. Given a string (str), length (len), and character (ch), left-pad will pad the left side of str with ch until the string length equals len.

为了理解为什么这甚至是一个辩论，我们应该首先了解left-pad 。 给定一个字符串(str)，长度(len)和字符(ch)， left-pad将用ch填充str的左侧，直到字符串长度等于len为止。

Here is the entirety of the code powering left-pad:

这是为左键盘供电的全部代码：

The idea that 17 lines of code (221 characters) was behind the implosion of the internet created a lot of complaints about the use of hyper-modular packages within the JavaScript community.

互联网崩溃的背后是17行代码(221个字符)的想法引起了很多人对JavaScript社区内使用超模块化包的抱怨。

So with that, (finally) I begin.

因此，(最后)我开始了。

npmgate与左键盘模块的大小无关 (npmgate had nothing to do with the size of the left-pad module)

The size of left-pad is a red herring. How many lines of code it contains is completely irrelevant to the discussion of how its removal from the npm ecosystem broke other packages. It could have been the removal of any package from the ecosystem which caused this.

左垫的大小是红色鲱鱼。 它包含多少行代码与从npm生态系统中删除它如何破坏其他软件包的讨论完全无关。 可能是从生态系统中删除了任何软件包造成的。

Azer removed 272 modules during his exodus from npm. It’s definitely safe to say that left-pad was written by a developer who has established himself in the community.

Azer在npm出走期间删除了272个模块。 可以肯定地说左护板 由在社区中立足的开发人员撰写。

Those who argue that having a dependency like left-pad adds risk to their project are essentially arguing against having any external npm dependancies in their project.

那些认为像左撇子这样的依赖关系会给他们的项目增加风险的人实质上是在反对在项目中拥有任何外部npm依赖关系。

是的，我们都可以从头开始编写类似左键盘的模块 (Yes, we can all write modules like left-pad from scratch)

But why would we want to?

但是我们为什么要呢？

The whole reason utility libraries like jQuery and lodash were created is to make the developer experience better.

创建实用程序库(如jQuery和lodash)的全部原因是为了使开发人员体验更好。

Sure the code behind left-pad is not very complex and it could probably be rewritten by any of us in a few minutes. Some may even enjoy the detour. That said, context switching from writing code solving the problem at hand to writing a method that manipulates strings seems like a poor use of time and energy. Remember, just because we can do something doesn’t mean we should.

确保左键盘后面的代码不是很复杂，并且我们中的任何人都可能在几分钟后将其重写。 有些人甚至可能会绕道而行。 也就是说，上下文从编写解决手头问题的代码到编写操纵字符串的方法的上下文切换似乎浪费了时间和精力。 请记住，仅仅因为我们可以做某事并不意味着我们应该这样做。

Everyday we should be enabling ourselves to focus on problems bigger and better than the day before.

我们每天都应该使自己能够专注于比前一天更大和更好的问题。

社区 (Community)

There is reason npm is outperforming all other package managers when it comes to growth. The barrier to entry to participate by publishing a package to npm is extremely small.

在增长方面，npm有理由胜过所有其他软件包管理器。 通过将软件包发布到npm来参与的障碍非常小。

Enabling more developers to participate in the process, regardless of the contribution size, can only cause the community to grow stronger.

无论贡献大小如何，使更多的开发人员都可以参与该过程，只能使社区变得更强大。

自由市场JavaScript (Free-market JavaScript)

Standards will probably never be able to keep up with the momentum and speed at which the JavaScript community is moving. This is OK. In this new world of free-market JavaScript, may the best module win. Good modules should grow as they get more downloads and community involvement, whereas modules not used or supported will slowly disappear into the virtual abyss. In fact, there are cases, such as bluebird, where the community library will out-perform the standard library (see Why are native ES6 promises slower and more memory-intensive than bluebird?)

标准可能永远无法跟上JavaScript社区发展的势头和速度。 还行吧。 在这个自由市场JavaScript的新世界中，最好的模块可能会赢。 好的模块会随着它们的更多下载和社区参与而增长，而未使用或未支持的模块将逐渐消失在虚拟的深渊中。 实际上，在某些情况下(例如bluebird) ，社区库的性能将超过标准库(请参阅为什么本机ES6承诺比bluebird速度更慢，内存占用更多​​？ )

So with all these modules how do you know which modules are safe to use? The truth is, as with any open source software, you never know for sure. But here’s the litmus test I use when including anything from npm in my project:

那么，对于所有这些模块，您如何知道哪些模块可以安全使用？ 事实是，就像任何开源软件一样，您永远无法确定。 但是，这是我在项目中包含npm中的任何内容时使用的石蕊测试：

1. Is the package well documented?
   包装是否有据可查？
2. Does it have tests?
   有测试吗？
3. Are people using it?
   人们在使用它吗？
4. Does the community have opinions about it (usually this only applies to larger modules)?
   社区对此有意见吗(通常仅适用于较大的模块)？

这与大小无关，与功能有关 (It’s not about size, it’s about functionality)

The beauty of our ecosystem is that modular development encapsulates responsibility and forces a separation of concerns. The size of the module should be irrelevant to the discussion, whereas the functionality is key.

我们生态系统的优点在于，模块化开发封装了责任，并迫使关注点分离。 模块的大小应该与讨论无关，而功能是关键。

The strength of any good hyper-modular package is that it will have a well defined interface, clearly documented, and well tested. Don’t we want all of our code to be composed from modules like that?

任何优质的超模块化封装的优势在于，它将具有定义明确的接口，明确记录并经过良好测试。 我们不希望我们的所有代码都由这样的模块组成吗？

模块是关于可组合性的 (Modules are about composability)

Think of node modules as lego blocks. You don’t necessarily care about the details of how it’s made. All you need to know is how to use the lego blocks to build your lego castle. — Sindre Sorhus from AMA #10

将节点模块视为乐高积木。 您不必关心其制作细节。 您只需要知道如何使用乐高积木来建造乐高城堡。 —来自AMA＃10的 Sindre Sorhus

In the end, this is all about composition. So, let’s continue building modules, let’s use those modules to build other modules, and those modules to build systems. Let’s compose those systems together to start building things that have never been done before.

最后，这一切都与构图有关。 因此，让我们继续构建模块，使用这些模块构建其他模块，并使用这些模块构建系统。 让我们将这些系统组合在一起，开始构建以前从未做过的事情。

Final note: I should be clear that I’m not saying that everything should be a tiny module. If anything, I’d like to see more large opinionated libraries in the community (another brain-dump for another day). In the meantime though, we should remember that some of the things being complained about right now are the same things that have made the JavaScript community so great.

最后说明：我应该清楚，我并不是说所有内容都应该是一个很小的模块。 如果有的话，我想在社区中看到更多大型的自以为是的图书馆(另一天动脑筋)。 但是，与此同时，我们应该记住，现在抱怨的某些事情与使JavaScript社区变得如此出色的事情相同。

Thanks.

谢谢。

翻译自: https://www.freecodecamp.org/news/in-defense-of-hyper-modular-javascript-33934c79e113/

捍卫者usb管理控制系统