跳到主要内容

ARC 2.0.0-beta.25

生成、lint 与迁移

保持 DSL source 可读，验证其语义；只有兼容消费者确实需要时才物化 JSON。

这些命令回答的不是同一个问题。某条命令变绿是有价值的证据，但不能代替在目标 renderer 中实际运行应用。

bash
arc dsl format ./hello-aup --write
arc dsl lint ./hello-aup
arc dsl validate ./hello-aup
arc dsl generate ./hello-aup --check

正确理解每一种结果

命令检查什么会不会写文件变绿后仍不能证明什么
format --writeDSL source 的格式会source 有效或可运行
format --check格式化是否会改文件不会生成产物是最新的
lint编写层面的 DSL 问题不会完整 app 配置与目标 renderer 一致
validate已解析 DSL/配置的语义不会浏览器或设备呈现了预期交互
generate --check兼容产物是否会变化不会source-first app 必须把 JSON 留在磁盘上
generate --write同一批产物会生成后的 app 已通过运行时验收

在 ARC 2.0.0-beta.25 的新鲜 minimal-app 样板中，format --write 会改写三份 DSL source。format_changed 是 format --check 在格式化会产生变更时给出的诊断；它不是 --write 命令的正常成功结果。

把生成的 JSON 当作兼容工作

DSL-first app 可以虚拟暴露兼容 JSON。只有某个明确的兼容消费者要求实体文件时，项目才需要把 JSON 写到磁盘。建议按以下顺序判断：

  1. 始终让 .aup source 作为权威来源。
  2. 在 CI，或交给需要生成文件的消费者前，运行 generate --check。
  3. 只有消费者确实需要实体产物时才运行 generate --write，并像审阅任何派生产物一样审阅 diff。
  4. 不要为了让项目“看起来像 DSL-first”而删除 JSON-first app；JSON 仍是受支持的 source 形式。

对于 AUP app 配置，存在的 .aup/app.aup 优先；它不存在时 ARC 才会把 .aup/app.json 作为 source 读取。DSL 文件存在但无效时，ARC 会失败，而不会悄悄回退到旧 JSON。这样无效 source 不会被陈旧产物掩盖。

用窄范围循环迁移

不要在同一步里同时改变 source 语言、UI 行为和部署边界：

  1. 先格式化、lint、validate 当前 source。
  2. 用生成 check 模式查看会有什么差异。
  3. 只有真实下游消费者需要时再物化。
  4. 运行声明 profile 的 arc blocklet check，再本地运行 blocklet 并查看实际目标。

命令边界见 CLI 诊断；loader 优先级见 Source、产物与 JSON 兼容性。