I'm trying to write a typescript definition file for an already existing library. This library (react-filepond) exports an object called File
(as can be seen in the usage example in the README).
The problem with that is that another one of the interfaces that this library creates utilizes the JS File interface.
So now in my typescript definition file I have to somehow manage two definitions of the type File
. My solution to this was to declare the object that the library creates as a different name in my definition file, and simply export it as "File".
declare class FilePondFile extends React.Component<FilePondFileProps> { }
export { FilePondFile as File };
That seems fine and dandy when I use the type in my own project. But as a proponent of OSS, I want to make this definition available to the community via the Definitely Typed repo.
Their linter give me an error though that is apparently preventing my PR from being reviewed:
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
At first glance it seems simple enough to remove the declare
that is in front of class FilePondFile
, however, if I remove it, I get a different error:
A 'declare' modifier is required for a top level declaration in a .d.ts file.
So I'm not sure how to handle this contradiction. The maintainers of Definitely Typed don't seem to have time to assist as my PR was just labeled "Needs Author Attention", despite my clear laying out of this problem.
Does anyone have a suggestion of what I can do to not duplicate the reference to File
in this definition file, while also passing the Definitely Typed linter?
The problem with that is that another one of the interfaces that this library creates utilizes the JS File interface.
There is another solution.
The File
name is taken by the class that's declared and exported from this module.
You have to describe FilePondItem
interface in the same module, and it must have file
property with File
type which is different - it must refer to a global File
object which is defined in lib.dom.d.ts
export interface FilePondItem {
file: File;
TypeScript types are structural. You don't have to refer to global File
type by name, you can provide its definition, compatible with the one in lib.dom.d.ts:
export interface FilePondItem {
file: Blob & {readonly lastModified: number; readonly name: string};
and everything will be just fine as long as type definitions will remain compatible.
There are drawbacks, of course: it's a duplicate code, it's more verbose, and there is a risk that it will become incompatible with actual File
in the future if global File
type changes (however I think that's unlikely).