我试图为一个已经存在的库编写一个打字稿定义文件。该库(react-filepond导出一个名为File
的对象(如usage example in the README所示)。
问题在于该库创建的另一个接口利用了JS File interface。
因此,现在在我的打字稿定义文件中,我必须以某种方式管理File
类型的两个定义。我的解决方案是在我的定义文件中将库创建的对象声明为另一个名称,然后将其导出为“文件”。
declare class FilePondFile extends React.Component<FilePondFileProps> { }
export { FilePondFile as File };
当我在自己的项目中使用该类型时,这看起来不错而花哨。但是作为OSS的支持者,我想通过Definitely Typed存储库向社区提供此定义。
他们的短毛绒给我一个错误,尽管它显然阻止了my PR的审查:
Error: C:/dev/DefinitelyTyped/types/react-filepond/index.d.ts:22:1
ERROR: 22:1 strict-export-declare-modifiers 'declare' keyword is redundant here.
See: https://github.com/Microsoft/dtslint/blob/master/docs/strict-export-declare-modifiers.md
乍看之下,删除declare
前面的class FilePondFile
似乎很简单,但是,如果删除它,则会收到另一个错误:
A 'declare' modifier is required for a top level declaration in a .d.ts file.
所以我不确定如何处理这个矛盾。尽管我明确指出了这个问题,但“确定类型”的维护者似乎没有时间提供帮助,因为我的PR仅被标记为“需要作者注意”。
有人建议我不重复定义文件中对File
的引用,同时还要传递定型短绒吗?
答案 0 :(得分:2)
问题在于,这是另一个接口 库创建利用了JS File接口。
还有另一种解决方法。
kube-dns
名称由从此模块声明并导出的类获取。
您必须在同一模块中描述File
接口,并且它必须具有FilePondItem
类型的file
属性,该属性是不同的-它必须引用全局File
lib.dom.d.ts
File
TypeScript类型是结构性的。您不必按名称引用全局export interface FilePondItem {
file: File;
类型,可以提供其定义,该定义与lib.dom.d.ts中的定义兼容:
File
并且只要类型定义保持兼容,一切都会很好。
当然有缺点:它是重复的代码,更冗长,并且如果全局export interface FilePondItem {
file: Blob & {readonly lastModified: number; readonly name: string};
类型发生更改,将来有可能与实际的File
不兼容(但是我认为这不太可能。
答案 1 :(得分:1)
此错误消息:
声明文件不导出任何内容时显示“ declare”修饰符对于 .d.ts文件。
。 declare
关键字是多余的,因为已经在*.d.ts
个文件中使用了该关键字。
拥有声明文件的目的是确切描述相应的JavaScript模块中正在发生的事情。 At the time of writing this post,react-filepond
包含3个命名的导出文件:const registerPlugin
,class FilePond
和class File
。这意味着您的声明可能如下所示:
types/react-filepond/index.d.ts
import * as React from 'react';
import { registerPlugin } from 'filepond';
export { registerPlugin };
interface Props { /* FilePond props here */ }
export class FilePond extends React.Component<Props> { }
export class File extends React.Component { }
因为那是模块中真正发生的事情。注意:如果没有filepond
的类型,最好先为该库创建类型。
如果使用者遇到命名冲突,则他们的职责是在本地提供别名:
import { File as FileComponent } from 'react-filepond';
由于每个人都有不同的设置,所以(作为打字作者)您无法避免遇到冲突。对于图书馆作者而言,避免这样的名称是一个好习惯,但是如果不使用这样的名称,则类型定义应遵循他们的选择。