让我们谈谈节点软件包
#javascript #node #deno

我制作了一个我想与大家分享的视频,但我知道您不在开发视频中,因此您在其中以文章形式获得了视频的转录,因此您可以在您自己的节奏(视频中有一些笑话,Tho)。希望您喜欢它:

成绩单

嘿!让我们谈谈开发。

如果您已经玩过节点软件包生态系统了一段时间,那么您就会知道这是一场噩梦。所以今天我的想法是将我的代码引起的眼泪变成对大家有用的东西。

依赖类型

首先,让我们谈谈依赖类型。我们有三种类型的依赖项:

  • 生产依赖性
  • 发展依赖性
  • 同伴依赖。

生产依赖性

生产依赖性在我们的package.json文件的"dependencies"属性中定义。使用包装时,我们在生产中使用的任何东西都需要在此处定义。这意味着,例如,如果我们使用的是utils库或包装中的类似库,则需要成为我们依赖性的一部分。因此,当我们的消费者安装我们的软件包时,他们将自动获得此依赖项的副本。

一个重要的注释是您需要避免,试图导入未定义的东西。假设它将在那里,因为它可能是依赖性或类似的依赖性。 避免不惜一切代价

发展依赖性

开发依赖性仅用于开发(DUH)。因此,在那儿,我们放置了测试引擎,编译器,捆绑器,衬里,更漂亮以及我们在那里拥有的所有甜蜜的东西之类的东西。这将由我们的合作者或任何其他开发人员在运行安装脚本时在我们项目上工作的任何开发人员安装,但消费者将无法获得开发依赖项的副本。

同行依赖

这些是最棘手的,因为它们不是由消费者或合作者自动安装的。它们需要手动安装。因此,在这里,我们将需要与包裹一起安装的东西放置,但是我们不能将其作为依赖性。这些案例确实很少见,但是如今,它们在诸如React之类的库中非常普遍,因为React不能因为图书馆的某些限制而成为依赖性,而是需要成为同行依赖性。为了在我们发展时拥有更好的经验,将某些东西作为同伴依赖性以及作为DEV依赖性是很常见的。因此,当某人在我们的图书馆工作时,他们会获得开发依赖性的副本,但是当某人消费我们的图书馆时,他们需要手动安装它。

版本控制

节点软件包“通常” 遵循语义版本。这只是定义三个数字的规格,该数字被点隔开,即:

MAJOR.MINOR.PATCH

修补

修补程序是我们进行修补或代码之类的错误或性能问题时会增加的数字。

次要的

当我们向包裹添加新的东西时,未成年人会增加。

主要的

专业可以包括所有以前的内容,但也有破坏的变化,这意味着我们以前公开的东西(例如函数)具有不同的参数或返回不同的东西。

版本范围

最后,如果您检查您的package.json,您会注意到我们在我们的语义版本旁边的Tildes(~)和Carets(^)等符号。这些符号用于定义我们将要安装的版本范围。

tilde(~)用于定义我们将安装只是一个补丁的东西,但我们不会超过当前的次要版本。

同时,Caret(^)定义了我们将安装任何高于或次要和补丁版本的内容,但绝不是专业,因为这引入了破坏变化。

语义版本操作令人惊讶,但问题在于它只是一个规格,因此有些人不会跟随它。例如,一个不遵循语义版本的非常流行的软件包是我所爱的人:打字稿。所以让我们谈谈有问题的包裹,我们可以吗?

有问题的软件包

当我们开始时,我告诉你这是一场[已编辑的]噩梦,我没有撒谎。

那里有非常受欢迎的软件包不会遵循语义版本,或者必须是同行依赖。

打字稿

打字稿不遵循语义版本操作。我喜欢这种语言,但是该语言由Microsoft拥有,Microsoft希望将版本控制用作某种营销移动,而不是实际遵循语义版本操作。因此,当他们发布补丁版本,次要版本或主要版本时,其中任何一个都可能包括打破更改,因为它只是营销。

反应

React确实很受欢迎,但它不能成为您的软件包的依赖性。它需要是同行依赖性和发展依赖性。

这是由于反应上下文中的局限性。因此,您需要将其作为同伴依赖性,因此使用您的软件包(使用React)的任何人都必须自己反应。

问题是,我们还没有触摸整个软件包生态系统中最糟糕的部分,那就是...

模块系统

很久以前,在远处的互联网上,节点的创建者瑞安(Ryan)决定使用commonjs作为节点的模块系统。有些人喜欢concomjs。我不是人。但是事实是,JavaScript本身并没有单独具有模块系统,所以这是时代的一个很好的方法。

过了一会儿,JavaScript本身引入了自己的模块系统,称为Ecmascript模块。这个新系统是当今几乎在任何地方使用的系统:importexport

在社区中来回的一些人之间,人们喜欢commonjs和人们宁愿使用语言所带来的东西的人们。节点16引入了对eCmascript模块的支持,基本上使其无处不在。但是如今,我们仍然有很多仍在使用commonjs的软件包。因此,这引起了构建系统和类似内容的一些冲突,试图使用ecmascript中的commonj,试图使用commonjs的ecmascript等等。

从我的角度来看,如果您今天要创建一个软件包,则应在Ecmascript中编写它。您不应该在common中写它。这是因为您想在任何地方,浏览器和节点以及运行JavaScript的任何地方提供代码。除非您使用某种捆绑器或编译器或其他任何东西,否则您将无法实现这一目标。

现在,如果您不相信eCmascript模块是必经之路的,那么也许您可以相信瑞安(Ryan)创造了超出节点的东西。让我们谈谈。

超越节点和NPM

我说的是,瑞安创造了一些新的东西,这就是所谓的...

不是

这只是单词的戏剧,因为node = deno,但它与使用ecmasiptions作为模块系统而不是commonjs的节点非常相似,但也解决了对安全性的很多问题。例如,默认情况下,它不允许您与网络进行交互。您需要实际上可以通过标志从CLI启用它。该工具很棒。我真的建议您尝试一下。

,但这并不是我们需要在节点周围更改整个生态系统,以实现CommonJ和Ecmascript模块之间的良好互动,而是可以使用一些为此设计的工具。最常见的一个,我今天推荐的一个称为...

快速地

vite允许您基本上编写代码,因为它是eCmascript。它将充分利用这一点,但是如果某些软件包过去仍在使用Commonjs,它仍然可以为您完成所有转换,并使其适合您的环境。所以,我真的建议您尝试一下,但这几乎就是今天。


如果您想阅读我不仅仅是抄录的更多文章,请查看my site中的文章:here

欢呼!