What is the process for setting up custom global interfaces in TypeScript using .d.ts files?

Question

What is the process for setting up custom global interfaces in TypeScript using .d.ts files?

I'm currently facing an issue in my ReactJS project using Webpack2 and TypeScript. Everything is functioning perfectly except for one thing - I've been struggling to move my self-written interfaces into separate files so they are accessible throughout the application.

Initially, I had all interfaces defined in files where they were being used, but as the project grew, I needed some interfaces to be shared among multiple classes, leading to complications. Despite modifying my tsconfig.json and relocating the files, both my IDE and Webpack continue to throw errors like "Could not find name 'IMyInterface'."

Here is a snippet from my current tsconfig.json:

{
  "compilerOptions": {
    // Compiler options here
  },
  // Exclude paths here
}

The tsconfig.json file resides in the root directory, source code in the ./src folder, and custom .d.ts files under ./typings, included in the typeRoots.

I have tested this setup with TypeScript versions 2.1.6 and 2.2.0 without success.

A possible solution involves moving the typings directory into src and then importing interfaces like so:

import {IMyInterface} from 'typings/blah'

. However, this approach does not feel right to me as it's unnecessary complexity. I want these interfaces to be seamlessly available across the entire application.

For example, a sample interface app.d.ts looks like:

interface IAppStateProps {}
interface IAppDispatchProps {}
interface IAppProps extends IAppStateProps, IAppDispatchProps {}

Do I need to export them or declare? Do I have to enclose them in a namespace?

Update (October 2020)

Given the ongoing popularity of this question, let me elaborate on the solution further.

typescript typescript-typings typescript2.0 typescript1.8

Answer 1

Answer №1

It is strongly advised to avoid relying on "Magically available interfaces" or global types, as this practice is generally considered outdated and should only be used for legacy purposes. Instead, when writing your own code, it is recommended to refrain from using ambient declaration files (such as d.ts files).

For defining interfaces and types in the code you are actively working on, it is best practice to utilize plain .ts files.

In Typescript, there are two main types of .ts files: 'scripts' and 'modules'. Anything declared in a 'script' file will have global scope, making it accessible throughout the entire application if included in the compilation process through various methods like ///<reference path="">, files:[], includes:[], or by default using **/*.ts in the tsconfig.json.

On the other hand, items defined within a 'module' file will be private to that module unless explicitly exported for use in other modules via import statements.

To differentiate between a 'script' and a 'module' in a .ts file, simply look for the presence of import/export statements. If these statements are present, the file is considered a 'module'; otherwise, it functions as a global 'script'.

If your interfaces are not behaving as expected and seem to be restricted to a specific module, chances are you accidentally introduced import or export statements in your declarations, converting them into a module. To maintain global accessibility for your interfaces, ensure that no import or export statements are used within the file.

Answer 2

It is strongly advised to avoid relying on "Magically available interfaces" or global types, as this practice is generally considered outdated and should only be used for legacy purposes. Instead, when writing your own code, it is recommended to refrain from using ambient declaration files (such as d.ts files).

For defining interfaces and types in the code you are actively working on, it is best practice to utilize plain .ts files.

In Typescript, there are two main types of .ts files: 'scripts' and 'modules'. Anything declared in a 'script' file will have global scope, making it accessible throughout the entire application if included in the compilation process through various methods like ///<reference path="">, files:[], includes:[], or by default using **/*.ts in the tsconfig.json.

On the other hand, items defined within a 'module' file will be private to that module unless explicitly exported for use in other modules via import statements.

To differentiate between a 'script' and a 'module' in a .ts file, simply look for the presence of import/export statements. If these statements are present, the file is considered a 'module'; otherwise, it functions as a global 'script'.

If your interfaces are not behaving as expected and seem to be restricted to a specific module, chances are you accidentally introduced import or export statements in your declarations, converting them into a module. To maintain global accessibility for your interfaces, ensure that no import or export statements are used within the file.

Answer 3

Answer №2

When working with global interfaces, it is important to remember that they are not "Magically available interfaces", but rather "global" interfaces.

In my .d.ts file, I extend the global Window interface in the following way:

export {};

declare global {
    interface Window {
        // This is just for IDE and/or TS-compiler purposes (defined in a .js file).
        myGlobalVariable: any;
    }
}

We can also create custom-global-interfaces using the same technique instead of extending existing ones.

For example:

import React from 'react';

declare global {
    interface MyGlobalInterface {
        myComponentField: React.Component;
    }
}

It's worth noting that .d.ts files do not generate output, so we can import any module as long as it is installed in the package.json.

In the above example, the export {}; line is not necessary because there is an import statement. The rule required at least one import or export at the time of writing.

Lastly, the name(s) and location(s) of the .d.ts files do not matter, but personally, I prefer placing the globals.d.ts file next to the root js/ts file of the project to ensure it is loaded first.

Answer 4

When working with global interfaces, it is important to remember that they are not "Magically available interfaces", but rather "global" interfaces.

In my .d.ts file, I extend the global Window interface in the following way:

export {};

declare global {
    interface Window {
        // This is just for IDE and/or TS-compiler purposes (defined in a .js file).
        myGlobalVariable: any;
    }
}

We can also create custom-global-interfaces using the same technique instead of extending existing ones.

For example:

import React from 'react';

declare global {
    interface MyGlobalInterface {
        myComponentField: React.Component;
    }
}

It's worth noting that .d.ts files do not generate output, so we can import any module as long as it is installed in the package.json.

In the above example, the export {}; line is not necessary because there is an import statement. The rule required at least one import or export at the time of writing.

Lastly, the name(s) and location(s) of the .d.ts files do not matter, but personally, I prefer placing the globals.d.ts file next to the root js/ts file of the project to ensure it is loaded first.

What is the process for setting up custom global interfaces in TypeScript using .d.ts files?

Update (October 2020)

Answer №1

Answer №2

For example:

Similar questions

Using TypeScript with React: Automatically infer the prop type from a generic parameter

Upgrade your development stack from angular 2 with webpack 1 to angular 6 with webpack 4

The element 'stripe-pricing-table' is not a recognized property of the 'JSX.IntrinsicElements' type

Combining results from multiple subscriptions in RxJS leads to a TypeScript compiler error

The utility of commander.js demonstrated in a straightforward example: utilizing a single file argument

Experiencing an issue with type error when transitioning syntax from using require to import

Handling Promises in Angular 1 App using Typescript ES6/2015

Streamline imports with Typescript

Tips for creating a recursive string literal type in Typescript

Enumerated types in Typescript: access the values

Updating the node startup file with Visual Studio 2015 using NodeJS/Typescript

Encountered an error stating 'name' property is undefined while using @input in Angular 2

ERROR Error: Uncaught (in promise): ContradictionError: The variable this.products is being incorrectly identified as non-iterable, although it

Is there a way to access every item that includes a particular attribute and attribute term within the woocommerce-rest-api?

Embrace the power of Angular2: Storing table information into

Guide to incorporating third-party libraries in Angular

I'm encountering an issue with my React 18 application using TypeScript: the module './App' cannot be found

Angular data table is currently displaying an empty dataset with no information available

Automatic type inference for TypeScript getters

Angular 2 - Ensuring service executes only when boolean condition is met