深入解析 lit localize 命令与 lit-labs/cli-localize从版本演进到源码实现【免费下载链接】litLit is a simple library for building fast, lightweight web components.项目地址: https://gitcode.com/GitHub_Trending/li/lit导读lit-labs/cli-localize是 Lit 生态中驱动lit localize命令的轻量级实现包负责将本地化子命令extract与build接入lit-labs/cli命令行工具。本文以该包的 CHANGELOG.md 为骨架结合其 README、命令实现源码 与lit/localize-tools的配置 schema完整梳理该包从 0.0.1 到 0.2.2 的演进脉络、命令分发架构、懒加载机制以及lit-localize.json配置文件的全部核心参数。读完本文你将理解lit localize命令背后CLI 壳 工具库的分层设计并能独立配置与运行本地化提取与构建流程。一、包定位lit-labs/cli-localize是什么根据 README该包的职责被明确概括为一句Powers thelit localizecommand驱动lit localize命令。它的定位是一个内部实现包文档明确要求开发者不要直接安装使用它而是安装lit-labs/cli运行lit localize命令该命令会从最近的node_modules目录加载本包如果找不到则主动提供安装选项。这一按需加载、就近解析的设计从 CHANGELOG 0.1.0 版本的变更说明中可以得到印证Locally version and lazily install the localize command对 localize 命令进行本地版本化并懒安装。也就是说lit-labs/cli-localize通过lit/labs/cli暴露lit localize入口而真正干活的是它依赖的lit/localize-tools见 package.json 中的lit/localize-tools: ^0.8.0。这种分层带来两个直接好处版本解耦lit localize的实现版本跟随项目node_modules就近解析不同项目可以使用不同版本的本地化工具链不会互相污染启动提速CLI 主程序不必在启动时加载本地化相关的全部重型依赖。二、命令分发架构元数据与实现分离从源码结构看lit-labs/cli-localize只有两个源文件却体现了清晰的工程分层src/index.ts定义命令的元数据命令名、描述、子命令、选项、默认值src/commands.ts定义命令的具体实现build/extract函数体。index.ts中的注释解释了这样拆分的原因这些元数据被用于--help命令和参数解析与实现分离是因为加载实现的全部依赖需要时间而如果加载每一个命令的实现依赖会严重拖慢 CLI 的启动速度。这正是懒加载在源码层面的落地index.ts中的run回调通过await import(./commands.js)动态导入实现模块见 src/index.ts只有当用户真正执行某个子命令时lit/localize-tools等重型依赖才会被加载进内存。getCommand()返回的命令对象结构如下摘自 src/index.tsexport const getCommand () { return { kind: resolved, name: localize, description: Lit localize, subcommands: [ { kind: resolved, name: extract, description: Extracts lit-localize messages, options: [ { name: config, description: The path to the localize config file, defaultValue: ./lit-localize.json, }, ], async run({config}: {config: string}, console: Console) { const commands await import(./commands.js); await commands.extract(config, console); }, }, // ... build 子命令结构与之对称 ], async run(_options: unknown, console: Console) { console.error( Use one of the localize subcommands, like lit localize build or lit localize extract. Run lit help localize for more help. ); return { exitCode: 1 }; }, }; };这里有几个值得注意的细节name: localize定义了 CLI 下的命令名即lit localize两个子命令extract与build各有一个--config选项默认值为./lit-localize.json顶层run在未指定子命令时打印引导提示并返回exitCode: 1相当于一个内置的用法检查kind: resolved表明该命令元数据在 CLI 启动阶段即可被静态解析无需加载实现。三、extract 与 build 子命令的源码级调用链commands.ts是lit localize真正的心脏它把命令转发给lit/localize-tools的底层能力。两个子命令的调用链如下摘自 src/commands.tsexport const build async (configPath: string, console: Console) { const config readConfigFileAndWriteSchema(configPath); const localizer makeLocalizer(config); console.log(Building); const {errors} localizer.validateTranslations(); if (errors.length 0) { throw new KnownError( One or more localized templates contain a set of placeholders (HTML or template literal expressions) that do not exactly match the source code, aborting. Details:\n\n errors.join(\n) ); } await localizer.build(); }; export const extract async (configPath: string, console: Console) { const config readConfigFileAndWriteSchema(configPath); const localizer makeLocalizer(config); console.log(Extracting messages); const {messages, errors} localizer.extractSourceMessages(); if (errors.length 0) { printDiagnostics(errors); throw new KnownError(Error analyzing program); } console.log(Extracted ${messages.length} messages); console.log(Writing interchange files); await localizer.writeInterchangeFiles(); };3.1 extract提取源消息并写出交换文件extract的执行流程是readConfigFileAndWriteSchema(configPath)读取并校验配置文件详见下文第四节localizer.extractSourceMessages()通过 TypeScript 程序分析见lit/localize-tools的 program-analysis.ts扫描源码中的msg()调用提取全部可本地化消息若分析出错调用printDiagnostics打印诊断信息并抛出KnownError(Error analyzing program)统计并打印提取到的消息数量Extracted N messageslocalizer.writeInterchangeFiles()将消息写入 XLIFF.xlf或 XLB 交换文件供翻译人员/翻译服务使用。3.2 build校验翻译并构建本地化产物build的执行流程是读取并校验配置localizer.validateTranslations()校验每个本地化模板中的占位符集合HTML 标签或模板字面量表达式是否与源码精确匹配若存在不匹配抛出KnownError并附上全部错误详情——这是build最重要的安全网防止因占位符顺序/数量错误导致生成损坏的本地化产物通过localizer.build()生成最终产物。3.3 makeLocalizer按输出模式分发makeLocalizer见 src/commands.ts根据配置中output.mode的值实例化不同的本地化器transform模式 →TransformLitLocalizer对应lit/localize-tools的 modes/transform.tsruntime模式 →RuntimeLitLocalizer对应 modes/runtime.ts其他值 → 抛出KnownErrorInternal error: unknown mode。这与lit/localize-tools独立 CLIsrc/cli.ts中的分发逻辑完全一致两个入口共享同一套LitLocalizer抽象只是lit-labs/cli-localize作为lit命令的子命令形式接入而后者是独立的lit-localize可执行文件。四、配置文件与完整参数说明两个子命令的--config选项默认指向./lit-localize.json。该文件由lit/localize-tools的readConfigFileAndWriteSchema读取、解析并校验见 src/config.ts校验依据是 config.schema.jsonJSON Schema draft-07。值得注意的一个贴心细节是若配置文件中缺少$schema属性工具会自动把 schema 引用写回文件从而让 VSCode 等编辑器获得校验与自动补全能力。下面按 schema 定义整理全部核心配置项4.1 顶层必填项字段类型说明sourceLocalestring必填。源码中消息所使用的语言代码例如entargetLocalesstring[]必填。需要本地化到的语言代码列表例如[es-419, zh_CN]inputFilesstring[]要提取消息的源码文件或 glob 模式。与tsConfig二选一必填若同时指定inputFiles优先tsConfigstringtsconfig.json 路径决定提取消息的源文件集合同时也是 transform 模式的编译选项来源。与inputFiles二选一必填interchangeobject本地化交换格式及配置XLIFF 或 XLB详见下文outputobject输出模式及配置runtime或transform详见下文patchesobject可选。对特定语言消息做字符串替换的补丁见 4.44.2 interchange交换文件格式字段类型说明formatxliff/xlb交换格式xliffDirstringxlf 格式必填。读写.xlf文件的目录每个目标语言对应xliffDir/locale.xlfplaceholderStylex/phxlf 格式可选。HTML 标记与动态表达式的占位符表示方式默认xx标签也可选phph标签用于适配不同翻译工具/服务的占位符语法outputFilestringxlb 格式必填。写入全部提取消息的 XLB XML 文件路径例如data/localization/en.xlbtranslationsGlobstringxlb 格式必填。读取已翻译 XLB 文件的 glob 模式例如data/localization/*.xlb4.3 output两种输出模式runtime 模式RuntimeOutputConfig字段类型说明moderuntime必填outputDirstring必填。生成模块的输出目录每个targetLocale会生成一个locale.ts模块按消息 ID 导出对应语言的翻译languagejs/ts生成模块的语言默认js若指定了tsConfig则默认tslocaleCodesModulestring可选。生成一个导出sourceLocale、targetLocales、allLocales的模块用于保持配置文件与客户端配置同步例如export const sourceLocale en; export const targetLocales [es-419, zh_CN]; export const allLocales [es-419, zh_CN, en];。路径以.js或.ts结尾决定生成模块的语言transform 模式TransformOutputConfig字段类型说明modetransform必填outputDirstring生成转换后项目的目录其中每个语言一个子目录包含该语言的完整项目构建。指定了tsConfig时默认取该配置的outDir两者同时指定时本字段优先localeCodesModulestring可选语义与 runtime 模式相同4.4 patches不重跑本地化周期的微调手段schema中的patches用于对特定语言的消息做字符串替换适合做小修正而无需修改源文件或重复完整本地化周期。官方示例patches: { es-419: { greeting: [ { before: Buenos dias, after: Buenos días } ] } }每个 Patch 由before要搜索的字符串与after替换为的字符串两个必填字段构成见 schema 中的 Patch 定义。4.5 一个最小可用配置示例结合 schema 与上文参数说明一个典型的 runtime 模式配置如下{ $schema: https://raw.githubusercontent.com/lit/lit/main/packages/localize-tools/config.schema.json, sourceLocale: en, targetLocales: [es-419, zh_CN], inputFiles: [src/**/*.ts], interchange: { format: xliff, xliffDir: xliff }, output: { mode: runtime, outputDir: generated/locales, language: ts, localeCodesModule: src/locale-codes.ts } }五、版本演进脉络从 0.0.1 到 0.2.2CHANGELOG 完整记录了该包的演进核心脉络如下0.1.0架构确立懒加载#2936 引入本包最关键的架构决策Locally version and lazily install the localize command。在此之前localize命令作为 CLI 内置功能存在此版本起改为独立的lit-labs/cli-localize包由lit localize从最近的node_modules加载找不到时提示安装。这一改动同时带来了版本隔离与启动性能收益对应上文第二、三节的源码设计。0.2.0TypeScript 版本升级#3814升级到 TypeScript v5.0#4141继续升级到 TypeScript ~5.2.0依赖同步更新lit/localize-tools0.7.0。这两个升级均发生在0.2.0-pre.1、0.1.1-pre.0预发布阶段逐步推进最终合并进 0.2.0 正式版。0.2.1依赖对齐依赖更新至lit/localize-tools0.8.0commit290a608a。该版本没有自身的功能变更纯粹是工具库版本对齐。0.2.2TypeScript 5.8 与 ARIAMixin 类型变更更新 TypeScript 依赖到 5.8并同步处理了相关的 ARIAMixin 类型变更涉及ariaColIndexText、ariaRelevant、ariaRowIndexText三个属性。这类更新虽然不改变命令行为但保证包在最新 TypeScript 编译器下的类型正确性与可持续构建。完整版本与依赖对照表版本类型关键变更依赖版本0.0.1初始包初始发布—0.1.0minor本地版本化 懒安装 localize 命令#2936—0.1.1-pre.0prereleaseTS v5.0#3814localize-tools 0.7.0-pre.00.2.0-pre.1prereleaseTS ~5.2.0#4141localize-tools 0.7.0-pre.10.2.0minorTS v5.0 TS ~5.2.0localize-tools 0.7.00.2.1patch仅依赖更新localize-tools 0.8.00.2.2patchTS 5.8 ARIAMixin 类型变更—六、与 lit/localize-tools 的关系两套入口同一内核值得注意的是本仓库同时存在两条功能对等的本地化 CLI 入口lit localize本文主题由lit-labs/cli承载实现在lit-labs/cli-localizelit-localize独立命令由lit/localize-tools直接提供其 cli.ts 定义了独立可执行入口。lit/localize-tools的 README 给出的独立用法为npm i -D lit/localize-tools lit-localize extract lit-localize build而lit-localizeCLI 的用法帮助信息cli.ts与lit-labs/cli-localize保持高度一致Usage: lit-localize [--configlit-localize.json] COMMAND Commands: extract Extract messages from source files build Build your project Options: --help Display this help message. --config Path to JSON configuration file. Default: ./lit-localize.json对比两处实现可以发现它们都复用readConfigFileAndWriteSchema、LitLocalizer、TransformLitLocalizer、RuntimeLitLocalizer等同一套lit/localize-tools核心对象lit-labs/cli-localize实际上是一层薄适配把命令实现挂载到litCLI 的子命令树中。因此无论走哪条入口lit-localize.json的配置格式与提取/构建行为都是一致的。七、运行与集成建议结合以上源码分析在实际项目中使用lit localize的标准流程是安装 CLI安装lit-labs/cli不要直接安装lit-labs/cli-localize并在项目中安装浏览器端运行时库lit/localize编写配置在项目根目录创建lit-localize.json按第四节配置sourceLocale、targetLocales、inputFiles/tsConfig、interchange与output提取消息运行lit localize extract或lit-localize extract生成 XLIFF/XLB 交换文件交由翻译流程处理构建本地化产物翻译完成后运行lit localize build或lit-localize build工具会先校验占位符一致性再生成各语言产物runtime 模式生成locale.ts翻译模块transform 模式生成整树本地化构建。若命令执行时提示找不到lit-labs/cli-localizeCLI 会引导从最近的node_modules解析或提供安装选项——这正是 0.1.0 版本确立的本地版本化 懒安装机制无需手动干预。结语lit-labs/cli-localize虽然是一个以 CHANGELOG 记之、体量极小的适配包却是理解 Lit 本地化工具链架构的钥匙它展示了CLI 元数据与实现分离按需动态加载本地版本化依赖等务实工程实践同时把extract/build的能力完整委托给lit/localize-tools。从 0.0.1 到 0.2.2 的演进也清楚呈现了该命令从内置走向独立、随 TypeScript 与工具库版本持续对齐的稳定发展路径。对于希望在 Lit 项目中落地多语言支持的开发者而言掌握lit localize的配置与命令语义即可直接套用 config.schema.json 的参数体系完成从提取、翻译到构建的完整本地化闭环。【免费下载链接】litLit is a simple library for building fast, lightweight web components.项目地址: https://gitcode.com/GitHub_Trending/li/lit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 lit localize 命令与 @lit-labs/cli-localize：从版本演进到源码实现
深入解析 lit localize 命令与 lit-labs/cli-localize从版本演进到源码实现【免费下载链接】litLit is a simple library for building fast, lightweight web components.项目地址: https://gitcode.com/GitHub_Trending/li/lit导读lit-labs/cli-localize是 Lit 生态中驱动lit localize命令的轻量级实现包负责将本地化子命令extract与build接入lit-labs/cli命令行工具。本文以该包的 CHANGELOG.md 为骨架结合其 README、命令实现源码 与lit/localize-tools的配置 schema完整梳理该包从 0.0.1 到 0.2.2 的演进脉络、命令分发架构、懒加载机制以及lit-localize.json配置文件的全部核心参数。读完本文你将理解lit localize命令背后CLI 壳 工具库的分层设计并能独立配置与运行本地化提取与构建流程。一、包定位lit-labs/cli-localize是什么根据 README该包的职责被明确概括为一句Powers thelit localizecommand驱动lit localize命令。它的定位是一个内部实现包文档明确要求开发者不要直接安装使用它而是安装lit-labs/cli运行lit localize命令该命令会从最近的node_modules目录加载本包如果找不到则主动提供安装选项。这一按需加载、就近解析的设计从 CHANGELOG 0.1.0 版本的变更说明中可以得到印证Locally version and lazily install the localize command对 localize 命令进行本地版本化并懒安装。也就是说lit-labs/cli-localize通过lit/labs/cli暴露lit localize入口而真正干活的是它依赖的lit/localize-tools见 package.json 中的lit/localize-tools: ^0.8.0。这种分层带来两个直接好处版本解耦lit localize的实现版本跟随项目node_modules就近解析不同项目可以使用不同版本的本地化工具链不会互相污染启动提速CLI 主程序不必在启动时加载本地化相关的全部重型依赖。二、命令分发架构元数据与实现分离从源码结构看lit-labs/cli-localize只有两个源文件却体现了清晰的工程分层src/index.ts定义命令的元数据命令名、描述、子命令、选项、默认值src/commands.ts定义命令的具体实现build/extract函数体。index.ts中的注释解释了这样拆分的原因这些元数据被用于--help命令和参数解析与实现分离是因为加载实现的全部依赖需要时间而如果加载每一个命令的实现依赖会严重拖慢 CLI 的启动速度。这正是懒加载在源码层面的落地index.ts中的run回调通过await import(./commands.js)动态导入实现模块见 src/index.ts只有当用户真正执行某个子命令时lit/localize-tools等重型依赖才会被加载进内存。getCommand()返回的命令对象结构如下摘自 src/index.tsexport const getCommand () { return { kind: resolved, name: localize, description: Lit localize, subcommands: [ { kind: resolved, name: extract, description: Extracts lit-localize messages, options: [ { name: config, description: The path to the localize config file, defaultValue: ./lit-localize.json, }, ], async run({config}: {config: string}, console: Console) { const commands await import(./commands.js); await commands.extract(config, console); }, }, // ... build 子命令结构与之对称 ], async run(_options: unknown, console: Console) { console.error( Use one of the localize subcommands, like lit localize build or lit localize extract. Run lit help localize for more help. ); return { exitCode: 1 }; }, }; };这里有几个值得注意的细节name: localize定义了 CLI 下的命令名即lit localize两个子命令extract与build各有一个--config选项默认值为./lit-localize.json顶层run在未指定子命令时打印引导提示并返回exitCode: 1相当于一个内置的用法检查kind: resolved表明该命令元数据在 CLI 启动阶段即可被静态解析无需加载实现。三、extract 与 build 子命令的源码级调用链commands.ts是lit localize真正的心脏它把命令转发给lit/localize-tools的底层能力。两个子命令的调用链如下摘自 src/commands.tsexport const build async (configPath: string, console: Console) { const config readConfigFileAndWriteSchema(configPath); const localizer makeLocalizer(config); console.log(Building); const {errors} localizer.validateTranslations(); if (errors.length 0) { throw new KnownError( One or more localized templates contain a set of placeholders (HTML or template literal expressions) that do not exactly match the source code, aborting. Details:\n\n errors.join(\n) ); } await localizer.build(); }; export const extract async (configPath: string, console: Console) { const config readConfigFileAndWriteSchema(configPath); const localizer makeLocalizer(config); console.log(Extracting messages); const {messages, errors} localizer.extractSourceMessages(); if (errors.length 0) { printDiagnostics(errors); throw new KnownError(Error analyzing program); } console.log(Extracted ${messages.length} messages); console.log(Writing interchange files); await localizer.writeInterchangeFiles(); };3.1 extract提取源消息并写出交换文件extract的执行流程是readConfigFileAndWriteSchema(configPath)读取并校验配置文件详见下文第四节localizer.extractSourceMessages()通过 TypeScript 程序分析见lit/localize-tools的 program-analysis.ts扫描源码中的msg()调用提取全部可本地化消息若分析出错调用printDiagnostics打印诊断信息并抛出KnownError(Error analyzing program)统计并打印提取到的消息数量Extracted N messageslocalizer.writeInterchangeFiles()将消息写入 XLIFF.xlf或 XLB 交换文件供翻译人员/翻译服务使用。3.2 build校验翻译并构建本地化产物build的执行流程是读取并校验配置localizer.validateTranslations()校验每个本地化模板中的占位符集合HTML 标签或模板字面量表达式是否与源码精确匹配若存在不匹配抛出KnownError并附上全部错误详情——这是build最重要的安全网防止因占位符顺序/数量错误导致生成损坏的本地化产物通过localizer.build()生成最终产物。3.3 makeLocalizer按输出模式分发makeLocalizer见 src/commands.ts根据配置中output.mode的值实例化不同的本地化器transform模式 →TransformLitLocalizer对应lit/localize-tools的 modes/transform.tsruntime模式 →RuntimeLitLocalizer对应 modes/runtime.ts其他值 → 抛出KnownErrorInternal error: unknown mode。这与lit/localize-tools独立 CLIsrc/cli.ts中的分发逻辑完全一致两个入口共享同一套LitLocalizer抽象只是lit-labs/cli-localize作为lit命令的子命令形式接入而后者是独立的lit-localize可执行文件。四、配置文件与完整参数说明两个子命令的--config选项默认指向./lit-localize.json。该文件由lit/localize-tools的readConfigFileAndWriteSchema读取、解析并校验见 src/config.ts校验依据是 config.schema.jsonJSON Schema draft-07。值得注意的一个贴心细节是若配置文件中缺少$schema属性工具会自动把 schema 引用写回文件从而让 VSCode 等编辑器获得校验与自动补全能力。下面按 schema 定义整理全部核心配置项4.1 顶层必填项字段类型说明sourceLocalestring必填。源码中消息所使用的语言代码例如entargetLocalesstring[]必填。需要本地化到的语言代码列表例如[es-419, zh_CN]inputFilesstring[]要提取消息的源码文件或 glob 模式。与tsConfig二选一必填若同时指定inputFiles优先tsConfigstringtsconfig.json 路径决定提取消息的源文件集合同时也是 transform 模式的编译选项来源。与inputFiles二选一必填interchangeobject本地化交换格式及配置XLIFF 或 XLB详见下文outputobject输出模式及配置runtime或transform详见下文patchesobject可选。对特定语言消息做字符串替换的补丁见 4.44.2 interchange交换文件格式字段类型说明formatxliff/xlb交换格式xliffDirstringxlf 格式必填。读写.xlf文件的目录每个目标语言对应xliffDir/locale.xlfplaceholderStylex/phxlf 格式可选。HTML 标记与动态表达式的占位符表示方式默认xx标签也可选phph标签用于适配不同翻译工具/服务的占位符语法outputFilestringxlb 格式必填。写入全部提取消息的 XLB XML 文件路径例如data/localization/en.xlbtranslationsGlobstringxlb 格式必填。读取已翻译 XLB 文件的 glob 模式例如data/localization/*.xlb4.3 output两种输出模式runtime 模式RuntimeOutputConfig字段类型说明moderuntime必填outputDirstring必填。生成模块的输出目录每个targetLocale会生成一个locale.ts模块按消息 ID 导出对应语言的翻译languagejs/ts生成模块的语言默认js若指定了tsConfig则默认tslocaleCodesModulestring可选。生成一个导出sourceLocale、targetLocales、allLocales的模块用于保持配置文件与客户端配置同步例如export const sourceLocale en; export const targetLocales [es-419, zh_CN]; export const allLocales [es-419, zh_CN, en];。路径以.js或.ts结尾决定生成模块的语言transform 模式TransformOutputConfig字段类型说明modetransform必填outputDirstring生成转换后项目的目录其中每个语言一个子目录包含该语言的完整项目构建。指定了tsConfig时默认取该配置的outDir两者同时指定时本字段优先localeCodesModulestring可选语义与 runtime 模式相同4.4 patches不重跑本地化周期的微调手段schema中的patches用于对特定语言的消息做字符串替换适合做小修正而无需修改源文件或重复完整本地化周期。官方示例patches: { es-419: { greeting: [ { before: Buenos dias, after: Buenos días } ] } }每个 Patch 由before要搜索的字符串与after替换为的字符串两个必填字段构成见 schema 中的 Patch 定义。4.5 一个最小可用配置示例结合 schema 与上文参数说明一个典型的 runtime 模式配置如下{ $schema: https://raw.githubusercontent.com/lit/lit/main/packages/localize-tools/config.schema.json, sourceLocale: en, targetLocales: [es-419, zh_CN], inputFiles: [src/**/*.ts], interchange: { format: xliff, xliffDir: xliff }, output: { mode: runtime, outputDir: generated/locales, language: ts, localeCodesModule: src/locale-codes.ts } }五、版本演进脉络从 0.0.1 到 0.2.2CHANGELOG 完整记录了该包的演进核心脉络如下0.1.0架构确立懒加载#2936 引入本包最关键的架构决策Locally version and lazily install the localize command。在此之前localize命令作为 CLI 内置功能存在此版本起改为独立的lit-labs/cli-localize包由lit localize从最近的node_modules加载找不到时提示安装。这一改动同时带来了版本隔离与启动性能收益对应上文第二、三节的源码设计。0.2.0TypeScript 版本升级#3814升级到 TypeScript v5.0#4141继续升级到 TypeScript ~5.2.0依赖同步更新lit/localize-tools0.7.0。这两个升级均发生在0.2.0-pre.1、0.1.1-pre.0预发布阶段逐步推进最终合并进 0.2.0 正式版。0.2.1依赖对齐依赖更新至lit/localize-tools0.8.0commit290a608a。该版本没有自身的功能变更纯粹是工具库版本对齐。0.2.2TypeScript 5.8 与 ARIAMixin 类型变更更新 TypeScript 依赖到 5.8并同步处理了相关的 ARIAMixin 类型变更涉及ariaColIndexText、ariaRelevant、ariaRowIndexText三个属性。这类更新虽然不改变命令行为但保证包在最新 TypeScript 编译器下的类型正确性与可持续构建。完整版本与依赖对照表版本类型关键变更依赖版本0.0.1初始包初始发布—0.1.0minor本地版本化 懒安装 localize 命令#2936—0.1.1-pre.0prereleaseTS v5.0#3814localize-tools 0.7.0-pre.00.2.0-pre.1prereleaseTS ~5.2.0#4141localize-tools 0.7.0-pre.10.2.0minorTS v5.0 TS ~5.2.0localize-tools 0.7.00.2.1patch仅依赖更新localize-tools 0.8.00.2.2patchTS 5.8 ARIAMixin 类型变更—六、与 lit/localize-tools 的关系两套入口同一内核值得注意的是本仓库同时存在两条功能对等的本地化 CLI 入口lit localize本文主题由lit-labs/cli承载实现在lit-labs/cli-localizelit-localize独立命令由lit/localize-tools直接提供其 cli.ts 定义了独立可执行入口。lit/localize-tools的 README 给出的独立用法为npm i -D lit/localize-tools lit-localize extract lit-localize build而lit-localizeCLI 的用法帮助信息cli.ts与lit-labs/cli-localize保持高度一致Usage: lit-localize [--configlit-localize.json] COMMAND Commands: extract Extract messages from source files build Build your project Options: --help Display this help message. --config Path to JSON configuration file. Default: ./lit-localize.json对比两处实现可以发现它们都复用readConfigFileAndWriteSchema、LitLocalizer、TransformLitLocalizer、RuntimeLitLocalizer等同一套lit/localize-tools核心对象lit-labs/cli-localize实际上是一层薄适配把命令实现挂载到litCLI 的子命令树中。因此无论走哪条入口lit-localize.json的配置格式与提取/构建行为都是一致的。七、运行与集成建议结合以上源码分析在实际项目中使用lit localize的标准流程是安装 CLI安装lit-labs/cli不要直接安装lit-labs/cli-localize并在项目中安装浏览器端运行时库lit/localize编写配置在项目根目录创建lit-localize.json按第四节配置sourceLocale、targetLocales、inputFiles/tsConfig、interchange与output提取消息运行lit localize extract或lit-localize extract生成 XLIFF/XLB 交换文件交由翻译流程处理构建本地化产物翻译完成后运行lit localize build或lit-localize build工具会先校验占位符一致性再生成各语言产物runtime 模式生成locale.ts翻译模块transform 模式生成整树本地化构建。若命令执行时提示找不到lit-labs/cli-localizeCLI 会引导从最近的node_modules解析或提供安装选项——这正是 0.1.0 版本确立的本地版本化 懒安装机制无需手动干预。结语lit-labs/cli-localize虽然是一个以 CHANGELOG 记之、体量极小的适配包却是理解 Lit 本地化工具链架构的钥匙它展示了CLI 元数据与实现分离按需动态加载本地版本化依赖等务实工程实践同时把extract/build的能力完整委托给lit/localize-tools。从 0.0.1 到 0.2.2 的演进也清楚呈现了该命令从内置走向独立、随 TypeScript 与工具库版本持续对齐的稳定发展路径。对于希望在 Lit 项目中落地多语言支持的开发者而言掌握lit localize的配置与命令语义即可直接套用 config.schema.json 的参数体系完成从提取、翻译到构建的完整本地化闭环。【免费下载链接】litLit is a simple library for building fast, lightweight web components.项目地址: https://gitcode.com/GitHub_Trending/li/lit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考