关于deno:deno编译问题

41次阅读

共计 2493 个字符,预计需要花费 7 分钟才能阅读完成。

deno 如果应用 typescript 进行开发,可能会遇到一个编译的问题,因为它会把 ts 文件编译为 js,再执行,但因为目前 deno 尚不是很稳固,有时候你会感觉匪夷所思,明明逻辑没有问题,但为什么运行后果就是不对呢?
这的确是 deno 的坑,上面咱们剖析下怎么解决这个问题。

咱们以前应用 nestjs 开发时,目录构造是这样的:

咱们留神到,执行 npm run dev 启动服务后,会生成一个 dist 目录,外面都是编译后的 js 文件。
而应用 deno 开发的话,并没有这个目录。它并非不生成,而是放在另外一个中央。

以我本机为例,执行 deno info:

DENO_DIR location

缓存文件的整体目录。前面几个都是它的子文件夹。

它能够通过设置环境变量 DENO_DIR 来进行批改。

Remote modules cache

也就是 deps 文件夹,其实就是咱们近程下载的文件。

能够看到,文件被 hash 化了。
值得注意的是,这 hash 值与 lock.json 文件中的 hash 值并不是间接对应的。
以 https://deno.land/std@0.110.0/path/separator.ts 文件在 lock.json 的 hash 为例,它的值是_8fdcf289b1b76fd726a508f57d3370ca029ae6976fcde5044007f062e643ff1c_,但在 deps/https/deno.land 目录下,其实是_8565f1188fdc3690450ed80e4ae0b6167f838da4ecd5c9dbb20497723935fc1_0 文件和它相关联的_8792e4b43e1cee8957317151086907b9bf36c7e8c17f7963a4d939ea486b7d72.metadata.json_。
前者的内容:

与 deno.land 上截然不同:

而后者的内容如下:

{
  "headers": {
    "cache-control": "public, max-age=31536000, immutable",
    "x-amz-request-id": "4CCZP09KD2XKWZZS",
    "content-type": "application/typescript; charset=utf-8",
    "date": "Fri, 17 Dec 2021 05:54:25 GMT",
    "server": "deploy/asia-east2-b",
    "x-amz-id-2": "Rm5JmINRF3YCv/kyP10DNS5Rlm0mSpFl8HkEZENifUEjfmmJc7u9xY2xAvtt+cny4taa9lfjSjM=",
    "x-amz-version-id": "CxnJt0wYBvGR8lbuUd1k3Nwv2biTn6fT",
    "access-control-allow-origin": "*",
    "last-modified": "Thu, 16 Dec 2021 16:30:42 GMT",
    "content-length": "259",
    "etag": "\"49cabf94e5bf1cea284f1df0cb1380aa\""},"url":"https://deno.land/std@0.118.0/path/separator.ts"
}

之所以不统一,应该是有一个值还加密了文件夹名称或者版本号之类,具体是怎么对应的,有趣味的同学能够钻研下。
这样不能不便找到编译后具体文件的结果是咱们很难像 Node.js 一样间接批改 node_modules 中文件进行本地调试。

Emitted modules cache

对应的是 gen 目录。猜想大略是 generate 的缩写。也就是一开始说到的,ts 编译后 js 所寄存的目录。

file 目录下就是咱们本地运行过 deno 的所有工程编译后的文件夹,而 https 就是咱们下载的近程文件编译后的代码。

每个 ts 文件会生成 2 个文件,一个后缀加了.js,一个后缀加了.meta。
前者就是编译后的 js 代码:

而后者是记录了版本号的 hash 值。

{"version_hash":"d8c590642ab47a3e9add6c86cb4b10c250447a861774a7b0cc8d693bc0f6c6bc"}

咱们说有时候编译会有问题,那遇到这种状况,就只能删除 gen 目录下对应的文件,或者暴力一些,间接把 gen 都干掉。惟一的影响只是代码运行时须要从新编译,耗时久一些。
可能有的同学被吓住了,这状况呈现的频繁吗?那还怎么开发啊?
我目前是进行目录挪动时偶然会呈现,可能是 typescript 的增量编译引起的,deno 集成它时哪里还有问题。心愿 deno 将来几个版本可能修复。

Language server registries cache

对应的 registries 目录。外面记录了些模块名称、版本号等。

Origin storage

对应 location_data 目录。这个目录是用来存储 localStorage 内容的,可见 deno 为了兼容浏览器生态真是很拼啊。

localStorage.setItem("myDemo", "Deno App2");
console.log(localStorage.getItem("myDemo"));

必须加 –location 参数运行,例如:deno run –location https://www.baidu.com storeTest.ts

这样,deno 的 location_data 目录下就会对应生成一个文件:

总结

本文通过 deno info,找到 deno 的缓存目录,简略介绍了下各文件夹对应的性能,遇到编译异样这种坑,能够有一种长期解决方案,而不致一头雾水。
deno 的生态也好,开发也好,目前处于可能也将长期处于倒退中阶段。官网团队当初也在迅速迭代中,每周一个小版本,每月一个大版本,足见其诚意。心愿大家多点儿急躁,也祝 deno 会越来越好。
当然,如果你打算用它投入生产,最好一个团队应用一个版本(准确到小版本),这样可能你的苦楚会少很多。没事儿不要轻易降级,因为你的第三方工具包很可能来不及兼容。

正文完
 0