@ 0disoft/ saylo 类型

富文本标签声明

当一个基础消息有明文 richText cLI 和背景 工人还排放 AppRichTextSchema 除了现有的 AppSchema数字 :

export type AppRichTextSchema = {
  "demo:terms": "link" | "strong";
  "demo:empty": never;
};

名称来自所配置的允许标签,包括未在 当前基础文本。 一个空标签列表变为 never; 无明确消息 合同省略。 没有丰富的合同,产生的产出保持不变. 只有标记的合同更改也更新了背景产生的声明. 这些声明载于 0.1.0。 。 。 . 见 严格的丰富文本类型 共享配置 以及可选的 React, Svelte, 和 Vue 渲染器检查.

生成 AppSchema 类型声明(.d.ts)来自萨伊洛基地目录. 运行 saylo-typegen CLI,或让 @0disoft/saylo-vite 在开发期间在背景中运行.

状态

在 Windows 上,如果重命名失败 EPERM, (中文(简体) ), EACCES,或 EBUSY作家重复了五次 总重试等待时间最多为620ms,如果新工作到来或等待时发电机被停止,则替换更早的工作被取消. 它不会先删除已有的文件 。 这一变动已列入 0.1.0-alpha.2 释放.

成功取决于实际持续到磁盘的产出。 如果更新的请求到达中间,已经写入文件的结果仍然被记录为成功,在一代失败重试后再次保存同一份目录,而不是跳过更早的结果. 这种行为包含在 0.1.0-alpha.4 释放.

writeGenerated(outFile, source, isCurrent?, { signal, operations }?) 输入 0.1.0-alpha.7 释放允许您输入文件 I/O、临时命名和替换操作。 取消返回 cancelled ,并在 I/O 步骤之间和替换重试时检查。 成功重命名后的取消不会改变 written。只有仅创建的临时文件才被清理,如果写出失败和清理失败重叠,则以原始失败为准. new TypeGenerator(outFile, { createWorker, write }?) 允许您为工人和作家注射疫苗,而之前工人的晚完成或失败不适用于新的工作.

这个读取器描述 0.1.0 (dist-tag语) latest) (中文(简体) ). 见 发布注释 用于范围和验证。 第一个出版的版本是: 0.1.0-alpha.1 从2026-10-06. 您也可以直接从仓库工作空间运行它 node packages/typegen/dist/cli.js。 。 。 .

安装

npm install --save-dev @0disoft/saylo-typegen@latest
npm install @0disoft/saylo-core@latest

稳定释放使用 latest 标签; 安装匹配版本的 Saylo 软件包. @0disoft/saylo-core 当您用核心通用软件消耗生成的类型时,需要使用。 仅生成类型声明时不需要。 如果已安装 CLI, 请使用 npx saylo-typegen 如下所示.

目录

使用 locales/<locale>/<namespace>.json 结构。 譬如说, locales/ko/demo.json 财务报告和审定财务报表 locales/en/demo.json。 。 。 .

{ "greeting": "안녕 {name}" }

{ "greeting": "Hello {name}" }

运行

移入下一个 i18 命名空间

saylo migrate --from i18next --file namespace.json --locale en --namespace common --json 预览 JSON-v4 命名空间转换。 使用 --escape-value false 仅当源应用程序已经禁用内插出时。 被嵌入的密钥,简单的插入和完整的正复数组被转换;不支持的行为块输出. --out-file new.json 专门建立一个目录 --base-file 与 --base-locale 检查现有的Saylo基地合同。 见 移徙指南。方案功能导出自 @0disoft/saylo-typegen/migrate中包含两个接口 0.1.0-alpha.7。 。 。 .

初始化已有的 Vite app

saylo init 默认预览集成; --apply 创建起动目录,共享配置,虚拟模块类型,打字店工厂,并连接静态的ESM Vite配置. 它保存相冲突的文件并打印出包管理器安装命令而不是运行它们. UI供应商和SSR请求/水分接线仍然清晰. 见 输入向导 用于需求、预览输出、清理和故障回收。 命令包含在已发布 0.1.0-alpha.7。 。 。 .

从应用程序目录中安装 CLI alpha 标记并运行 :

npm install --save-dev @0disoft/saylo-typegen@latest
npx --no-install saylo init --base-locale en --json
npx --no-install saylo init --base-locale en --apply --json

共用配置和目录检查(alpha.5)

loadProjectConfig() 编辑 saylo 当前检出中的命令不在npm中 alpha.4 释放。 现有 saylo-typegen 参数得到保留,新的 --config 选项读取与 Vite 相同的 JSON 配置。 JSON以外的配置代码没有执行.

{
  "format": "saylo-project/v1",
  "localesDir": "locales",
  "baseLocale": "ko",
  "checkLocales": ["en", "fr"],
  "typegen": { "outFile": "generated.d.ts" }
}

将以上内容另存为 saylo.config.json。相对于包含配置文件的目录解决路径. richText 使用与 Vite 相同的命名空间 → 消息ID → 允许的标签列表,声明的密钥必须在基目录中存在. checkLocales 是完整的 CLI 检查的方位;不是将方位添加到 Vite 的设置。 在省略时,它会检查它找到的地方,包括空目录. initialLocale 也包含在支票中.

在安装了α.5或后期的工程中,使用以下命令. --no-install 使用已安装的可执行文件而不下载其他软件包.

npx --no-install saylo-typegen --config saylo.config.json
npx --no-install saylo check --config saylo.config.json --json
npx --no-install saylo sync --config saylo.config.json --dry-run --json

在寄存器中,建起后,您可以用 node packages/typegen/dist/catalog-cli.js check --config examples/vanilla/saylo.config.json --json。香草示例的Vite插件读取相同的配置.

check 报告JSON,ICU,论据,以及丰富的合同错误,不在底部的翻译密钥,以及缺失的命名空间和信件一起. 明确指定的完整性目标中缺少的条目是检查中的错误,即使运行时间可以倒回基址. 空译字符串作为有效译名处理. 它不会猜测和删除源代码中未使用的密钥 .

sync --dry-run 打印一个 add, (中文(简体) ), review,以及 retain 计划. translation: null 附加表示它尚未被翻译,也不是实际目录值。 现有译名及不在底部的密钥或取名空间被保留,并提议不替换被打碎的文件. export, (中文(简体) ), snapshot,以及 refresh 无 --out-file,以及 check 财务报告和审定财务报表 sync,只读,不写目录、生成类型或审查记录。 没有删除或自动翻译功能。 将翻译到目录的唯一命令是 import --apply。 。 。 .

以下内容: snapshot 财务报告和审定财务报表 baseline 示例使用不使用的较早的仅基线审查方法 reviews。如果使用批准分类账,请跟踪 可选翻译核准记录 本文稍后部分.

要比较源变化, 首先保存 stdout snapshot 到一个文件。 审查记录只存储了每条消息的源文本和丰富的合同中的SHA-256,而不是源文本或翻译内容.

npx --no-install saylo snapshot --config saylo.config.json > saylo-baseline.json
npx --no-install saylo check --config saylo.config.json --baseline saylo-baseline.json --json
npx --no-install saylo sync --config saylo.config.json --baseline saylo-baseline.json --dry-run --json

你也可以把那个 baseline 在共享的 JSON 路径。 如果指定了路径但文件缺失或无效,则命令失败. snapshot 不读取现有基准。 无 --out-file 它会打印出新的比较基线到 stdout; 随它而写出一个新的文件。 虽然 baseline 在配置中指向同一路径, snapshot 不读取,所以当文件不存在时,您可以创建第一个基线。 建立基线记录不是翻译批准;翻译不完整是可能的,但如果任何目录无效,则被拒绝. check 财务报告和审定财务报表 sync 不更新记录。 如果源文本或允许的标记更改,则会标出现有的翻译 SOURCE_CHANGED;如果新源文本已有译出,则标出 SOURCE_ADDED。 。 。 . reviewTracking 实值 "not-configured" 只有在没有的时候 baseline 也没有 reviews 指定;仅限 baseline 这是 baseline,仅包含 reviews 这是 approvals,与两者是 baseline-and-approvals在进行人工审查后,更新比较基线.

在不更新现有比较记录的情况下 --out-file,将 stdout 保存到新文件中,确认退出代码 0 和内容,然后替换原文件。 直接在已存在的基线上重定向可以让 shell 在命令失败前将已存在的文件截取. 可用 --out-file,且现有文件没有被覆盖.

安全文件输出( alpha.5)

--out-file <new.json> 仅支持 export, (中文(简体) ), snapshot,以及 refresh。没有它,现有的 stdout 输出和只读行为保持不变。 相对路径由 cwd 解决,必须有一个 .json 扩展名。 父目录必须实际存在, 并且不能是同义链接, 路径不能在内 locales 或指向输入工作文件、配置、实际读取的基准或审查路径。 现有的文件、目录和同义链接被拒绝,没有 --force 或覆盖选项.

在构建并验证了整个输出JSON之后,它会写到同一个目录中一个独有的临时文件,关闭它,然后用硬链接发布新文件. 现有文件没有被覆盖 。 不支持硬链接的文件系统安全失败并清理临时文件. 关于成功,Stdout只包含一张收据, {"format":"saylo-file-output/v1","command":"export"|"snapshot"|"refresh","writtenFiles":[absolute paths],"blocked":boolean},以及 --json 无需。 实际工作文件,快照,或刷新JSON到指定的文件,以及 blocked 是已保存内容的屏蔽状态.

npx --no-install saylo export --with-context --out-file translation-work.json --config saylo.config.json
npx --no-install saylo snapshot --out-file saylo-baseline.json --config saylo.config.json
npx --no-install saylo refresh --file translation-work.json --out-file refresh-report.json --config saylo.config.json

如果 JSON 验证 export 或者说 snapshot 失败, 它不会创建出文件; 它会打印现有的诊断结果到 stdout并退出 1 . refresh 当 workfile 实值 null当有冲突时 workfile ,它保存了完整的报告并仍然退出 1。 使用和输出出错 第2出错;取消为SIGINT 130和SIGTERM 143. 当需要保存已有文件时,请使用 --out-file 而不是弹壳重定向.

进出口翻译工作文件(alpha.5)

export 财务报告和审定财务报表 import 仅存在于当前取出中,而不在npm中 alpha.4。 。 。 . export 只缺少指纹 add 职业和 review 任务,其源文本或丰富的合同相对于基线更改或被添加为JSON的 stdout。 其中不包括 retain 保留现有翻译的条目。 输出格式为 saylo-translation-work/v1。 。 。 .

npx --no-install saylo export --config saylo.config.json > translation-work.json

将源变化审评纳入先前不使用的唯一基准方法 reviews,添加 --baseline saylo-baseline.json 或设置 baseline 在配置中。 没有基线,只有 add 工作被释放。 如果目录无效, 当 --out-file 未指定,它打印a saylo-check/v1 报告为 stdout 而不是工作文件并退出 1。 纵然如此 --out-file,验证失败不会产生出文件,并打印出同样的诊断结果。 导出不包含 --out-file 不写入磁盘,所以将 stdout 保存到新文件中,确认退出代码和内容,然后替换已有的工作文件.

这个 source, (中文(简体) ), sourceHash,以及 originalTranslation 每个入境点都是出口时的检查站。 仅更改 translation 并离开其他田地. originalTranslation 实值 null 用于 add 条目和 a review 条目从现有的翻译开始。 如果你留下一个 review 未加修改的条目,其 translation 等于 originalTranslation,因此在导入时跳过. translation: null 工作尚未完成 "" 是一个有效的翻译.

{
  "format": "saylo-translation-work/v1",
  "baseLocale": "ko",
  "entries": [
    {
      "locale": "en",
      "namespace": "demo",
      "id": "greeting",
      "reason": "add",
      "source": "안녕 {name}",
      "sourceHash": "763db49e97b5a0937ce680dc9d9b5ac57b79408890eddf3ed4829d85cf13a617",
      "originalTranslation": null,
      "translation": "Hello {name}"
    }
  ]
}

这个 sourceHash 在示例中只显示形状。 这不是一个文件, 它显示您仅更改的窗体 translation 在导出结果中,并在真实文件中保留导出时写入的值.

指定 export --with-context 发射 saylo-translation-work/v2 添加 context 每个条目。 没有选项, 它会保留 v1, 并且条目会保留现有的 8 个字段, 没有 context。 。 。 .

{
  "context": {
    "arguments": {
      "count": ["number"],
      "at": ["date", "number"],
      "name": ["number", "string"]
    },
    "richTextTags": ["link"]
  }
}

arguments 告诉您哪些参数和哪些类型是基础方案允许的,这并不意味着在翻译中必须使用每一个参数。 你可以像以前一样省略争论. richTextTags: null 表示丰富的政策不适用,因此标记形状可能是正文; [] 表示没有允许标记的丰富模式; 诸如 ["link"] 是许可列表.

npx --no-install saylo export --with-context --config saylo.config.json > translation-work-v2.json

import, (中文(简体) ), approve,以及 refresh 自动读取 v1 和 v2。 这个 context v2的结构得到验证,但其内容是信息;实际 sourceHash, ICU, 参数, 标记, 和批准验证使用当前目录和配置 。 编辑 context 不能改变允许的规则. --with-context 仅由 export 财务报告和审定财务报表 refresh; 其他命令退出 2。 此选项和v2格式包含在α.5.

import 需求 --file 并且就是其中一个 --dry-run 或者说 --apply。 。 。 . --dry-run --json 只打印验证结果和更改列表,以及 --apply --json 撰写翻译,将验证通过目录.

npx --no-install saylo import --file translation-work.json --dry-run --json
npx --no-install saylo import --file translation-work.json --apply --json

import --dry-run --diff 使用相对于 localesDir,不更改文件。 新建文件从 --- /dev/null,而无新线在文件端的标记和 CRLF 线的结尾在 diff 中保存. --diff 仅使用 import --dry-run,并使用它与 --apply 或者另一个命令是使用错误(exit 2).

npx --no-install saylo import --file translation-work.json --dry-run --diff

--diff --json 添加a diff 字符串到现有的 saylo-translation-import/v1 报告。 当被封锁时,它会返回 diff: null 退出 1; 当没有变化时, 返回 diff: "" 并离开 0。 正常被屏蔽的输出只打印现有的诊断和摘要,而不打印diff.

您只能完成一些条目 。 它跳过条目 translation 实值 null 或等于 originalTranslation,且已应用的再导入值不执行写入。 如果单个条目无法验证,则整个应用程序被屏蔽.

它验证工作文件格式,基础地块,地块/名空间/id,以及复制. 目标路径由根下和命名空间下方的cononical locale目录来构建,而不是信任工作文件中所写的路径. 如果源文本或丰富的合同在导出后更改,则与 SOURCE_CONFLICT;如果现有的翻译不同于 originalTranslation它挡住 TRANSLATION_CONFLICT,因此再次导出并重做这项工作。 它还验证了JSON,ICU参数,以及每个文件的合并结果的丰富的标记.

--apply 每个文件编写临时文件并重命名, 重试时 EPERM, (中文(简体) ), EACCES,或 EBUSY 发生在 Windows 上。 它在写入前重新检查路径, 如果存在同义链接或交叉点, 则失败 。 它在开始第一个替换前分级并验证所有输出,但它不会将多个文件组合成一个交易. 如果出现迟到的I/O或争吵失败,则先前编写的文件可能保留 writtenFiles 报告 --json 列出错误 。 它不会覆盖已经写好的文件来滚动它们 .

.saylo-import.lock 与Saylo进口同时进行。 如果一个进程被杀死,锁可能还会被保留,因此在检查里面所写的pid实际上已经结束后,手动删除所剩的锁.

在替换和重命名重写之前进行字节比较可以检测到介于两者之间的编辑,但这不是一个文件系统 CAS,它阻止了另一个编辑器在上一个检查和重命名之间写入.

import --apply, (中文(简体) ), approve --apply,以及 export, (中文(简体) ), snapshot,以及 refresh 与 --out-file 作为中止符号接收SIGINT和SIGTERM。 在一个信号上,他们停止了进一步的写作和出版,等待飞行中I/O和清理手柄,临时文件,和锁,然后离开. 它们不会向后滚动一个原子重命名或一个已成功发布的出文件硬链接,与信号同时完成的文件仍然准确报告在 writtenFiles。第一个信号优先,在清理过程中反复发出的信号不会迫使立即退出。 正常出站和故障均去除CLI信号收听器. 取消退出代码为SIGINT 130和SIGTERM 143;其他一般错误为 2.

对a --json 注销 import --apply 或者说 approve --apply,现有 saylo-command-error/v1 error 获得 cancelled: true, (中文(简体) ), signal: "SIGINT"|"SIGTERM",以及 writtenFiles: [...],则 message 解释原因保存. --out-file 在同一取消之后, writtenFiles和清理保证。 没有干运行和只读路径 --out-file 不受影响。 SIGKILL,强制终止Windows,或失去电能并不能保证清理,所以现有的手动stale-lock检查政策仍然保留.

--apply 仅替换已存在的文件中已更改的字符串符号,保留密钥顺序、缩进、行尾、最终新行和未修改的逃生拼写,并使用结肠周围的现有间隔、缩进和换行样式附加新密钥。 多行空物体使用2-空格缩进,而新文件则使用2个空格,LF,并使用最终的新行. 无关的密钥和孤儿密钥都保留在原地.

import 不重建类型声明或基准。 申请后运行 saylo check 和类型生成(saylo-typegen)分别. 更新基准与翻译批准分开.

刷新翻译工作文件(alpha.5)

refresh 将进行中的工作文件与最新文件合并 export 候选人和印刷品a saylo-translation-refresh/v1 报告到Stdout。 与 --out-file,实际报告被写到文件, Stdout得到收据。 即使没有 --json,整个stdout是一个单一的JSON文档,报告包含 blocked, (中文(简体) ), workfile, (中文(简体) ), conflicts, (中文(简体) ), alreadyApplied,以及 report。 。 。 . workfile 实值 saylo-translation-work/v1 或者说 saylo-translation-work/v2,并且已经 null 如果目录无效, 例如来自 JSON, ICU, 参数, 或丰富的政策错误 。 对删除的源密钥或命名空间的剩余翻译仍然进行比较并显示为 SOURCE_REMOVED· ; UNKNOWN_MESSAGE 财务报告和审定财务报表 NAMESPACE_MISMATCH 保存在 report 但仅这两个诊断并不能阻挡候选生成,目录也不会被删除. report 是目录检查结果 。 若为 workfile 实值 null,没有 --out-file 创建.

npx --no-install saylo refresh --file translation-work.json --config saylo.config.json > refresh-report.json
# exit 0과 내용을 확인한 뒤
jq '.workfile' refresh-report.json > refreshed-work.json

--config 或者说 --locales 确定目录,以及 --baseline 财务报告和审定财务报表 --reviews 申请情况 export没有批准分类账,它可以从空分类账开始,比如 export,但指定 baseline 丢失失败 . refresh 写入任何输入工作文件、目录、基线、批准分类账,或生成的报告以外的类型 --out-file它不接受 --apply 或者说 --dry-run这些是使用错误.

如果来源和丰富的散列和当前目录翻译没有从 originalTranslation 在工作文件中,它将内容保存在 translation。 。 。 . null 将空字符串保留为在建状态,并新建 add 财务报告和审定财务报表 review 来自最近导出的字段包含并按地块、命名空间和代号排序.

refresh 保留v1用于v1输入和v2用于v2输入,并重新计算v2 context 从最新值。 给定 --with-context 用 v1 输入将其推广到 v2; 新建工作和 conflicts.current 获取最新 context时 conflicts.previous 财务报告和审定财务报表 alreadyApplied 从输入中保留快照 .

SOURCE_REMOVED, (中文(简体) ), SOURCE_CONFLICT, (中文(简体) ), TRANSLATION_CONFLICT,以及 UNKNOWN_TARGET 放置在 conflicts 作为 { code, previous, current }。 。 。 . previous 是原始条目,并且 current 是最近的一个条目或 null,保留源文本和书面翻译. translation 内 conflicts.current 实值 null,并删除相冲突的密钥 workfile.entries。用于冲突 current,审查最新的源文本,填写 current.translation,然后添加到候选人中。 删除或排除目标条目 current: null,然后运行 refresh 再来一次.

如果当前目录翻译等于书面翻译,那么书面翻译不同于 originalTranslation中,前面的条目添加到 alreadyApplied。 。 。 . workfile 保留一个可审查的条目,其 originalTranslation 财务报告和审定财务报表 translation 既是当前翻译. import 本条目为 " 无 " ,审批由下列单位单独处理: approve。在 alreadyApplied 决定.

整份报告不是输入或批准的投入。 使用 refreshed-work.json从顶层提取 workfile 与 jq接下来的一步。 报告至今仍未完成 exit 1检查 conflicts[].previous 财务报告和审定财务报表 current,用手编辑工作文件,并取出.

可选翻译核准记录(alpha.5)

reviews 是一个可选特性,将当时经批准的地块和密钥绑入源和翻译散列. 打开 {"reviews": "saylo-reviews.json"} 在共享 JSON 中,或添加 --reviews 改为 check, (中文(简体) ), sync, (中文(简体) ), export, (中文(简体) ), refresh,或 approve。当未指定时,保留现有的仅基线行为。 分类账只存储来源和丰富的合同散列和每个地方/名称空间/id的翻译散列.

若为 requireReviewedTranslations: true 财务报告和审定财务报表 reviews 都设置在共享 JSON 中 SayloProjectConfig, Vite 生产建筑,读取相同的配置也执行批准检查。 此选项默认为 false,以及 true 无 reviews 在Vite dev 也被拒绝.

当您首先启用它时,目标地块的现有译名也需要明确的批准. check 财务报告和审定财务报表 sync 丢失分类账时失败( 退出 2),同时 export, (中文(简体) ), refresh,以及 approve 从空记录开始. export 不写入分类账, 并发送所有已翻译的现有密钥为 review 任务.

npx --no-install saylo export --reviews saylo-reviews.json --locales en > review-work.json
npx --no-install saylo approve --reviews saylo-reviews.json --file review-work.json --dry-run --json
npx --no-install saylo approve --reviews saylo-reviews.json --file review-work.json --apply --json

保留您在查看工作文件时已经核实过的翻译字符串 。 对于尚未核实的条目, 设置 translation 改为 null 或从文件中删除。 条目 translation: null ; 保留其价值不变的现有译文, 也允许您明确批准。 如果当前来源或丰富的散列或翻译在导出后有所改变,则它会作为冲突块块并不会部分应用. import --apply 也不自动批准翻译.

approve --apply 只为已核实的条目添加批准记录,不写目录、基准或类型声明。 对其他地方或密钥的现有批准得到保留,建立新的基线不会改变批准分类账或未经批准的状态. 批准后,更改来源为 SOURCE_CHANGED,修改的译名是 TRANSLATION_CHANGED,没有记录的密钥是 REVIEW_REQUIRED。 。 。 . check, (中文(简体) ), sync, (中文(简体) ), export,以及 refresh 都应用分类账报告这些状况.

分类账必须是 .json 外部文件 locales。在写入时,母目录必须实际存在,并且不能是同义链接,而拒绝一个同义链接分类账路径。 同一分类账由一对指向锁进行序列化并被原子重命名所取代. 强制终止留下的锁在检查自有的pid已终止后被删除.

退出代码为: check 正常时为0;有诊断时为1; sync 生成计划时为0;被屏蔽时为1;例如被无效目录所屏蔽; snapshot 0 当正常, 1 当无效目录 . export 创建工作文件时退出 0, 无效目录退出 1 ; import 财务报告和审定财务报表 approve 当预览可用或应用程序完整时退出 0 , 当冲突或验证失败而阻塞时退出 1 。 取消 --apply 或者说 --out-file 是SIGINT 130和SIGTERM 143,其他一般错误为 2. refresh 没有冲突的候选人退出 0,冲突或无效目录退出 1,使用、文件系统或工作文件格式错误退出 2。 无 --json{\fn黑体\fs22\bord1\shad0\3ahbe\4ah00\fscx67\fscy66\2chffffff\3ch808080}你为什么这么觉得 refresh 是一份JSON报告. --json 其它命令出错也作为 Stdout 上的 JSON 文档返回,帮助不读取磁盘. 现有 saylo-typegen 0和1的退出代码被保留.

以现有参数生成类型

npx saylo-typegen --locales-dir locales --base-locale ko --out-file generated.d.ts

验证每个目录之后 --locales-dir,它写了基础语言的申报。 如果一个无效的翻译文件存在,则会出错. AppSchema 从上面的目录中生成的有形状 { "demo:greeting": { "name": number | string } }; 数字为 number,普通插值为 number | string,日期为 Date | number. 任何ICU分支中使用的参数也根据需要生成.

连接生成的 AppSchema 到核心的通用软件.

import { readFile } from 'node:fs/promises';
import { parseCatalog, createStore } from '@0disoft/saylo-core';
import type { AppSchema } from './generated.js';

const read = async (locale: string) => parseCatalog(
  await readFile(`locales/${locale}/demo.json`, 'utf8'),
  { locale, namespace: 'demo', sourceName: `locales/${locale}/demo.json` },
);

const store = createStore<AppSchema>({
  baseLocale: 'ko', locale: 'en', timeZone: 'UTC',
  catalogs: [await read('ko'), await read('en')],
});
console.log(store.t('demo:greeting', { name: 'Saylo' })); // "Hello Saylo"
store.dispose();

在JavaScript项目中,将相同的密钥和参数检查与JSDoc连接 /** @type {import('@0disoft/saylo-core').Store<import('./generated.js').AppSchema>} */。 。 。 .

--help 财务报告和审定财务报表 -h 打印选项和实例以退出和退出 0。 帮助不读取目录或写入输出文件 .

Usage: saylo-typegen --locales-dir <directory> --base-locale <locale> --out-file <file.d.ts>

Required options:
  --locales-dir <directory>  Directory containing locale/namespace.json catalogs.
  --base-locale <locale>     Base BCP 47 locale, for example ko or en-US.
  --out-file <file.d.ts>     Generated declaration file; must end in .d.ts.

  --config <file.json>      Shared project settings; explicit flags override their paths relative to cwd.

  --help, -h                Show this help without reading or writing files.

Example:
  saylo-typegen --locales-dir locales --base-locale ko --out-file generated.d.ts

All catalogs are validated before writing. Invalid catalogs leave existing output unchanged.

缺少所需的选项, 未知选项, a --base-locale 非BCP 47形式,或 --out-file 不结束于 .d.ts 是一个使用错误。 它写着消息和提示 Run saylo-typegen --help for options and an example. 至 stderr, 1出入口, 并留 stdout 为空 。 这个 --out-file 扩展和 --base-locale 检查在从磁盘读取目录之前运行, 因此在文件 I/ O 之前无效的选项失败 。 修复选项, 并再次运行相同的命令 。 输出文件必须是的限制 .d.ts 并且保留最后有效产出并在解剖上取而代之的合同保持不变。 这种帮助和早期验证包含在α.5中,并且没有包含在α.4.中.

构建秩序

顺序为ttygen → tsc → vite. 因为Vite建筑不检查消费者的TS类型,先运行tsc. 添加中 typegen: { outFile: 'generated.d.ts' } 到 Vite 插件最初在 Dev 中生成,然后在背景中更新,它不会在只修改副本时重写声明.

相关软件包

• @ 0disoft/ saylo 核心 消费 AppSchema
• @0disoft/saylo-vite (英语) ——以 dev 为单位的自动生成
• @ 0disoft/ saylo 反应 ——打入的钩子

文档

• 实时更新和类型
• 仓库 读取

版本数

支持节点.js 24.x. engines.node 实值 24.x,本地核查环境为节点24.18.0。 它与类型Script 7 和 typescript 不作为同行执行.

它是一个CLI和工人在节点上运行,运行时间目标为ES2022.

问题和安全报告

发送一般问题、 特性建议和错误到 [email protected] (英语)包含软件包和版本,环境,预期和实际行为,以及从合成数据中构建的最小复制. 将安全问题私下报告给同一电子邮件 Saylo security 主题。 不要发送指使符,密钥,饼干,或真实的用户数据.

如果您安装了Vite 软件包, 您可以在 node_modules/@0disoft/saylo-vite/docs/support.md 财务报告和审定财务报表 security.md。这些指南和软件包的联系元数据包含在α.5中。 早期的α.4焦油丸并不含.

许可证

阿帕奇2.0 (英语). 分布式柏油球包括寄存器根 LICENSE 财务报告和审定财务报表 NOTICE。 。 。 .