CSDN|Deno 是面向代码的浏览器？( 二 )

Laurie Voss：“但我们的代码还是存放在同一个地方，也就是GitHub 。因为维护软件生态系统是一项社会工作，需要影响力，这必然导致中心化的系统，这与技术要求无关。 ”

GitHub已成为开源的源头，因为它很好用且能够解决问题，而且是建立在广为接受的代码管理工具git上的。从Deno CLI的角度来说，代码来自何处并没有技术限制，因此生态系统完全决定了怎样才能让Deno更易于发现，也许最后的方式是CLI的创建者从来没有想到过的。
可重复的构建在npm生态系统中这是一个问题。由于npm严重依赖语义版本控制，依赖于node.js/npm生态系统带来的复杂的依赖关系图，因此很难保证可重复的构建。 Yarn引入了锁定文件的概念，而npm紧随其后。我感觉这就像一条摇着尾巴讨好主人的狗一样，生态环境中的开发者们造成了问题，然后就弄出一个不完善的解决方案来解决。长期使用这个生态系统的人都知道，许多问题的解决方法就是rm -rf node_modules package-lock.json && npm install 。

本文插图
话虽如此， Deno为此提供了两种解决方案。首先是Deno缓存模块。可以将缓存提交到源代码控制中，同时使用--cached-only标志确保不尝试检索远程模块。 DENO_DIR环境变量可用于指定缓存的位置，以提供更大的灵活性。其次， Deno支持锁定文件。 --lock lock.json --lock-write可以输出一个锁定文件，记录所有依赖项的哈希值。之后可以使用--lock lock.json对依赖进行验证。还有一些其他命令支持可重复的构建。 deno cache将解决给定模块的所有依赖关系，并填充Deno缓存。 deno bundle可用于生成工作负载的单个文件的“构建” ，所有依赖关系都已解决并包含在该文件中，以后可以使用deno run命令运行该文件。
信任代码我认为这是另一个我们的思维比较奇怪的地方。出于某种原因，我们信任来自中心式仓库的代码。对于这些代码我们根本不会考虑信任问题。不仅如此，我们还相信这些代码的所有依赖项都是可以信赖的。我们快速搜索一下然后输入npm install some-random-package ，然后就认为一切没问题。我认为，丰富的npm软件包生态系统让人们感到沾沾自喜。为了弥补这种松懈和自满，我们在工具链中实现了安全监视软件，分析依赖项以及成千上万行代码，以找出那些可能有问题的代码。企业会设置私有仓库，对于信任的要求要比公共仓库高一些。人们对此熟视无睹。其实最好的策略是我们不应该信任任何代码。做到这一点之后，再去信任某些代码就会容易一些。但是如果我们认为程序包管理器和中心化仓库可以解决此问题，甚至可以实质性地解决此问题，那就是在会自欺欺人。实际上，我认为它们的存在让我们放松了警惕。 “因为是npm上的，如果出现有问题的包，那么肯定有人会把它取下来。 ” Deno在这方面的工作还不尽如人意，但它有一个好的开始。它在开始时采用零信任，并提供相当精细的权限管理。我个人不喜欢的一件事是-A标志，它基本上等于“允许一切” 。对于沮丧的开发人员而言，允许一切要比弄清楚真正的需求要容易得多。这些权限也再细分，比如说“这段代码可以做这个，但是其他代码不能做” ，或者根据代码的来源来决定是否允许提权，这些代码是从哪里来的。希望我们能找到一种易于使用的机制，并结合一些在运行时有效且高效的方法来尝试解决这些难题。不过，最近有一个变化我认为很好，那就是Deno不再允许导入来源的降级。如果某个东西是从https://导入的，那么只能从其他https://的地方导入。这跟浏览器不能降级传输协议是一样的。我认为，从长期来看，禁止一切非https://的导入是必要的，就像Service Workers要求HTTPS一样。我们将拭目以待。