共计 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 会越来越好。
当然，如果你打算用它投入生产，最好一个团队应用一个版本（准确到小版本），这样可能你的苦楚会少很多。没事儿不要轻易降级，因为你的第三方工具包很可能来不及兼容。