typescript - 在类型定义文件中定义类型与在普通类型文件中定义类型的好处

Question

对于应用程序代码，是否建议将 Redux 存储类型放在 state-slice.d.ts 中？文件？
我继承了一个代码库，其中所有核心类型都放在 .d.ts 中。定义文件，但这与我对定义文件的作用的理解相反。
我的理解是，定义文件适用于编写库时(这是作者集中一个接口(interface)以定义我们向消费者公开的库的 API 的方便位置)，但不适合应用程序代码，因为数据可以快速变化。
也就是说，我无法提出反对 .d.ts 的好论据。文件本身 - 从功能的角度来看，我没有看到引用类型的区别

declare namespace Domain {
  interface State {
    // ...
  }
} 

从定义文件，或从具有

export interface ReduxState {}

要添加更多上下文，因为这是一个有点奇怪的问题 - 我目前正在开发一个新项目，该项目需要从我继承的现有代码库中共享这些核心类型，我正在尝试将这些类型移动到单独的包。
不幸的是，我在导入和导出这些类型时遇到了问题 - 似乎我必须(注意 export s)

/* package A */
export declare namespace StateA { }

/* package B */
import { StateA } from 'packageA/StateA' 

const stateA: StateA = {};

而不是 TypeScript 自动拾取它。

/* package B (originally) */

// stateA.d.ts
declare namespace StateA {}

// test.ts
const stateA: StateA = {};

我试过改变 typeRoots tsconfig.json 中的字段文件以查看是否可以避免插入 import处处说法，无济于事。
我认为这可能是将所有类型定义文件转换为普通类型文件的好机会，但除了“我认为我们不应该使用类型定义文件”和“我无法让定义类型中的类型像现在一样工作”。
所以我的问题是

使用类型定义文件比在普通中定义类型有什么好处.ts文件？

在处理面向消费者的应用程序代码时，我们是否应该编写自己的定义文件？

是不是我想的太多，真的无所谓？

如果这个问题有点开放，我会提前道歉，我希望这不适合 StackOverflow 社区(或者如果是的话，什么是一个很好的论坛？)。谢谢!

Answer 1

你看到这个答案了吗How do I use namespaces with TypeScript external modules?
我不完全同意它，但我认为值得一看。我最近也问了我所有这些问题。e
这是我一直在做的事情:
对于仅在一个文件或几个文件中使用的类型，我从常规 ts 定义和导出它们文件。
例如:
store.ts
该文件定义了一个 APP_THUNK仅由处理 redux thunk 创建的少数文件使用的类型。所以，我正在定义和导出这个文件，因为它使用 ROOT_STATE此处也定义的类型。

import { configureStore } from "@reduxjs/toolkit";
import { rootReducer } from "./rootReducer";
import { Action } from "@reduxjs/toolkit";
import { ThunkAction } from "redux-thunk";

export interface ROOT_STATE {
  ...
}

export type APP_THUNK = ThunkAction<
  Promise<void> | void,
  ROOT_STATE,
  unknown,
  Action<string>
>

export const store = configureStore({
  reducer: rootReducer
});

然后，当我需要使用这些类型时，我会导入它们: import { APP_THUNK } from "@redux/store";但我也有一些类型在我的整个项目中使用，在很多文件中。对于那些类型，我保留 d.ts文件并使用 declare namespace SOME_NAMESPACE 使其可访问.
例如:
BLOGPOST.d.ts
该文件定义了与 blogPost 相关的所有类型。对象。

declare namespace PROJECT {

  interface BLOGPOST {
    id: string,
    slug: string,
    images: BLOGPOST_IMAGE[]
  }

  interface BLOGPOST_IMAGE {
    id:        string,
    src:       string,
    alt:       string,
    caption:   string,
  }

  // AND SO ON...
  // THERE ARE MANY MORE TYPES HERE RELATED TO BLOGPOSTS  

}

我也合并了 PROJECT来自不同文件的命名空间。例如: PRODUCTS.d.ts还声明 namespace PROJECT它会自动与 BLOGPOSTS.d.ts 上的那个合并.
使用这些类型非常方便:

interface Props {
  blogPost: PROJECT.BLOGPOST
}

// OR MAYBE

const blogPost = await API.getBlogPost() as PROJECT.BLOGPOST;

并且自动完成立即在该命名空间下分组。我认为这也很好。

这对我有用。请考虑到我是一个人工作，而且这种类型仅在这个项目中使用。不知道这种模式是否适用于多人团队或跨不同项目。
另请注意，在 Typescript offical docs 中，我们得到:

Using Modules

Modules can contain both code and declarations.

Modules also have a dependency on a module loader (such as CommonJs/Require.js) or a runtime which supports ES Modules. Modules provide for better code reuse, stronger isolation and better tooling support for bundling.

It is also worth noting that, for Node.js applications, modules are the default and we recommended modules over namespaces in modern code.

Starting with ECMAScript 2015, modules are native part of the language, and should be supported by all compliant engine implementations. Thus, for new projects modules would be the recommended code organization mechanism.

但我仍然认为，当您使用这些类型时，当您在模块上使用命名空间时会获得更好的开发体验。但请注意命名空间冲突，因为它们是全局的。