deno.jsonc 而不是 package.json。在混合项目里,deno.jsonc 会与 package.json 并存,承载 Deno 原生的配置。无论哪种方式,extension dev 和 extension build 的行为都是一样的。
用 Deno 创建项目
主模式:deno.jsonc 就是项目清单
当你在 Deno 运行时下生成脚手架时,deno.jsonc 会成为项目唯一的清单文件,package.json 会被移除。
- 模板的依赖会以
npm:说明符的形式进入imports,由deno install负责解析。 extension引擎本身也声明在那里,形式为npm:extension@<version>。nodeModulesDir被设为"auto",因此npm:依赖会落到一个真实的node_modules目录里。打包器在 dev 和 build 时都从那里解析项目依赖。deno task <name>也会在node_modules/.bin中查找可执行文件,所以生成的任务运行的是本地安装的 Extension.js CLI。
deno.json 而不是 deno.jsonc,所以合并的目标就是 Deno 实际会读取的那个文件。
伴随模式:deno.jsonc 与 package.json 并存
monorepo 模板,以及那些已经有package.json 的项目,会保留它。依赖仍然声明在 package.json 中,由 deno install 从那里解析。作为伴随文件的 deno.jsonc 只承载 Deno 原生的配置,以及用来运行 CLI 的 tasks。
工具链如何检测 Deno
检测依据的是文件,而不是你用什么方式调用 CLI:- Extension.js 在扫描项目依赖时会读取
deno.jsonc或deno.json。框架、CSS 和 TypeScript 的检测都能看到imports通过npm:说明符声明的包。 - 当两份清单声明了同一个包时,以
package.json中的条目为准。 - 一个项目被视为由 Deno 管理,需要它有
deno.lock,或者有一份 Deno 配置且旁边没有package.json。对混合项目来说,npm 家族的锁文件优先;而且只有当deno可执行文件在你的 PATH 上时,才会认定为 Deno。
Deno 项目中的 TypeScript
TypeScript 的检测规则与别处完全相同。参见 TypeScript:由 SWC 编译源码,typescript 包只在做 tsc --noEmit 时才需要。

