如何像在 babelrc 中创建依赖别名一样在 typescript 中创建类型别名？

Posted 2023-03-13

【中文标题】如何像在 babelrc 中创建依赖别名一样在 typescript 中创建类型别名？

【英文标题】：How to create typings alias in typescript the way we create dependency alias in babelrc？

【发布时间】：2020-06-24 05:07:21

【问题描述】：

TL;DR:

如何在 typescript 中创建打字别名，就像我们在 babelrc 中创建依赖别名一样？

完整的问题：

假设我正在为iOS 和网络 进行开发，并且想只编写一组代码。我正在使用React-Native 和一个与React-Native 非常相似的接口，为了这个问题，我们称它为Respond-Native（一个虚构的名称）。

在项目中，我使用了一个名为<Picker /> 的组件。 Respond-Native 上的 Picker（仍然是 自制 库）有一个在 React-Native 中不存在的属性，称为 onSwipe。

但除此之外，界面的其余部分几乎相同。像这样的微小差异遍布Respond-Native。

为了让打字更容易，我有两个几乎相同的项目。 唯一不同的是我给使用Respond-Native的项目的.babelrc添加了别名：

// .babelrc


  ...
  "plugins": [
    ...
    ["module-resolver", 
      "root": ["./"],
      "alias": 

        // the alias is here
        "react-native": "respond-native"

      
    ]
  ]

但是，当我写<Picker onChange=handleOnChange onSwipe=handleOnSwipe /> 时，编辑器不知道依赖别名，也不知道prop onSwipe 来自哪里。

抱歉拖了这么久。

我的问题是，如何在创建类型别名时做同样的事情（就像我在 babelrc 中所做的那样），以便 VS Code 在检查类型时知道使用哪种类型声明？ （假设 Respond-Native 也声明了 Picker 类型/接口）

【参考方案1】：

TS 具有与 babel 完全相同的机制，即路径别名：

tsconfig.json

  "compilerOptions": 
    "paths": 
      // ...
    
  

但是，由于此配置仅适用于用户源代码而不适用于任何node_modules 的限制，它需要一些努力来“引导” TS 以了解您的意图。

例如，preact 是一个 API 与 react 非常相似的库。假设您使用 react 编写代码，稍后您想切换到 preact 但不想更改代码。

您按如下结构组织文件

./
├── node_modules/
│   ├── react/
│   └── preact/
├── typings/
│   └── react/
└── src/
    └── main.ts

添加tsconfig.json：

  "compilerOptions": 
    "baseUrl": ".",
    "paths": 
      "*": ["typings/*"]
    
  

此配置告诉 TS 在解析任何模块时首先查看 typings/ 文件夹。如果有匹配项，则使用它，否则，回退到查找 node_modules/。

通过这个设置，加上一个软链接，我们可以将react 的类型定义重定向到preact 之一。

ln -s $PWD/node_modules/preact/src/index.d.ts $PWD/typings/react/index.d.ts

【讨论】：

感谢您的回答！这听起来可能很愚蠢，但如果 TS 要先查看typings/，我可以在其中同时输入 react 和 preact 类型吗？顺便说一句，preact 很棒！（虽然也许你不是想推广它）我想我会在我的下一个项目中使用它。

是的，你可以。您还可以创建自己的自定义index.d.ts 文件，以选择性地公开/修改原始库的类型定义。做import Component from "react"; interface MyComp extends Component ... ; export MyComp as Component ; 随便。

关于 preact 库我并不是要推广它。我个人认为 preact 唯一的好处是减少了捆绑包的大小。缺点是与以反应为中心的生态系统集成可能会很麻烦。你在这里和那里遇到细微差别，导致难以发现的意外问题。 :-/

如果我要宣传任何东西，请尝试 svelte 代替您的下一个项目 ;-)

LOL 我会试试这个技巧并回复你。 Svelte 看起来很有希望。一定会尝试的！另外，感谢您对 preact 的内部看法。