关于typescript:为-i18next-json-配置文件生成-dts-类型定义

场景

吾辈有一些我的项目须要应用 i18next 来解决国际化，然而应用 typescript 须要有类型定义，所以之前在 joplin-utils 我的项目中保护和应用。昨天做了很多重构，当初曾经分离出来并作为公共 npm 包公布。如果有人感兴趣，能够尝试一下。

English, 简体中文

简介

i18next 的 typescript 类型定义生成器，能够从多个语言翻译 json 文件中生成类型定义，反对嵌套对象与参数。

应用

这个 cli 自身国际化配置的类型定义生成也是由 cli 实现的（自举）

yarn add -D @liuli-util/i18next-dts-gen
i18next-dts-gen --input src/i18n # 扫描这个目录下的 json 文件并生成 index.d.ts 类型定义 

详情

$ i18next-dts-gen -h
Usage: bin [options]

依据 json 生成 .d.ts 类型定义

Options:
  -i, --input <input...>  蕴含一或多个翻译文件的目录
  -w, --watch             是否应用监督模式
  -h, --help              display help for command

动机

为什么曾经有了很多第三方的类型定义生成器，甚至最新版 i18next 官网曾经推出了 typescript 解决方案，吾辈还要写这个呢？

简而言之，都不欠缺。

先从 i18next 官网的解决方案说起，它是将 json 文件替换为 ts 文件，但不能反对参数和嵌套对象。

注：最新版仿佛利用了 typescript 4.2 的递归类型和模板字符串类型来保障类型平安，但这实际上是不怎么好用的。另外只有 react-i18next 是可用的。

• i18next typescript support
• StackOverflow i18next 的类型定义

再来说 i18next-typescript 这个第三方库，简直能满足吾辈的需要了，除了一点：反对对象参数。还有像是 Jack 菊苣的 i18n-codegen，代码设计上十分优雅，但同样的，不反对 react 之外的生态。

另外，就吾辈而言，认为应用生成器生成简略的类型要比从类型零碎上反对这种性能更加容易，也更加正当。

设计

FAQ

是否反对 i18next 的全副个性？

否，这里反对的仅为 i18next 的一个子集。

• [x] 为多个本地化 json 配置文件生成类型定义

• [x] 反对蕴含参数

  • [] 不反对对象参数
• [x] 反对嵌套的 key
• [] 不反对配置命名空间、嵌套的宰割字符串，咱们认为约定大于配置
• [] 不反对 json 之外的配置文件，咱们认为 json 文件对于非开发者都更敌对，而且在须要时开发者更容易解决
• [] 不反对 i18next 命名空间，行将翻译文件宰割