Although this question is quite old, I recently encountered similar issues, making it still relevant.

An alternative solution involves adding

declare module "*.api";

to your index.d.ts file. However, this approach comes with a major drawback of sacrificing type safety since items in a shorthand module declaration are assigned the type any. This essentially nullifies the purpose of generating TypeScript interfaces from the start.

I found a workaround that seemed to work, even though I don't fully comprehend its inner workings.

package.json

Please note that I've utilized the most recent versions of all components at the time of writing, opting for ts-loader over the outdated awesome-typescript-loader.

{
  "name": "so-example",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "build": "webpack"
  },
  "dependencies": {
    "ts-loader": "^9.2.8",
    "typescript": "^4.6.3",
    "webpack": "^5.70.0",
    "webpack-cli": "^4.9.2"
  }
}

webpack.config.ts

The necessity of using appendTsSuffixTo is well-documented and vital, but not entirely sufficient on its own.

I unearthed the thinly documented resolveModuleName option for ts-loader. By delving into the depths of the ts-loader codebase and closely examining input-output relationships within the function, I devised the custom resolver function below. Adding a .ts extension to the

resolvedFileName</code was necessary to deceive the TypeScript compiler into validating the file.</p>
<p>Note that this <code>ts-loader

configuration must be applied to both rules, which led me to encapsulate it within a variable.

// webpack config setup
const path = require('path');

const tsLoader = {
  loader: "ts-loader",
  options: {
    appendTsSuffixTo: [/\.api$/],
    resolveModuleName: (moduleName, containingFile, compilerOptions, compilerHost, parentResolver) => {
      if (/\.api$/.test(moduleName)) {
        const fileName = path.resolve(path.dirname(containingFile), moduleName);
        return {
          resolvedModule: {
            originalFileName: fileName,
            resolvedFileName: fileName + '.ts',
            resolvedModule: undefined,
            isExternalLibraryImport: false,
          },
          failedLookupLocations: [],
        };
      }
      return parentResolver(moduleName, containingFile, compilerOptions, compilerHost);
    },
  },
};

module.exports = {
  entry: './index.ts',
  output: {
    filename: 'output.js',
  },
  resolveLoader: {
    alias: {
      'my-own-loader': path.resolve(__dirname, "my-own-loader.js"),
    },
  },
  module: {
    rules: [
      {
        test: /\.api$/,
        exclude: /node_modules/,
        use: [tsLoader, "my-own-loader"],
      },
      {
        test: /\.tsx?$/,
        exclude: /node_modules/,
        use: [tsLoader]
      },
    ]
  },
};

tsconfig.json

It's unclear why this step is imperative, but without it, an error message stating

TS18002: The 'files' list in config file 'tsconfig.json' is empty.

arises.

{}

my-own-loader.js

I included a demonstration to corroborate our retention of type safety.

module.exports = function(source) {
  return `
export interface DummyContent {
    name: string;
    age?: number;
}

export const DUMMY_VALUE: DummyContent = {
    name: "Jon Snow",
    age: 24,
}
`;
};

index.ts

Notice how I import the file featuring the .api extension. While it may be feasible to tweak the resolveModuleName function to operate sans extension, I opted not to pursue this route. I prefer having the extension as a visual indicator denoting something unique is happening here.

import { DUMMY_VALUE } from './example.api';

console.log(DUMMY_VALUE.name); // Compiles successfully
console.log(DUMMY_VALUE.youKnowNothing); // Does not compile

If you have an API that adheres to the swagger spec, there is a handy npm package called swagger-ts-generator that allows you to automatically generate TypeScript files from it:

Generate TypeScript Code from Swagger

This node module helps in creating TypeScript code for Angular (version 2 and above) by utilizing Web API metadata in Swagger v2 format.

All you need to do is provide it with the swagger URL, and it will do the heavy lifting of generating TypeScript files. While the examples provided are geared towards Gulp, they can easily be adapted for WebPack as well:

var swagger = {
    url: 'http://petstore.swagger.io/v2/swagger.json',
    //url: 'http://127.0.0.1/ZIB.WebApi.v2/swagger/docs/v1',
    swaggerFile: folders.swaggerFolder + files.swaggerJson,
    swaggerFolder: folders.swaggerFolder,
    swaggerTSGeneratorOptions: {
        modelFolder: folders.srcWebapiFolder,
        enumTSFile: folders.srcWebapiFolder + 'enums.ts',
        enumLanguageFiles: [
            folders.srcLanguagesFolder + 'nl.json',
            folders.srcLanguagesFolder + 'en.json',
        ],
        modelModuleName: 'webapi.models',
        enumModuleName: 'webapi.enums',
        enumRef: './enums',
        namespacePrefixesToRemove: [
        ],
        typeNameSuffixesToRemove: [
        ]
    }
}

My modified version of Mike Patrick's code offers several enhancements.

Instead of exporting a type or interface from the loader, I export an "abstract class."

This results in a better developer experience.

• No need to import any concrete class/variable
• Correct typings are provided on the first build
• However, creating a globals.d.ts is necessary

Check out my fork here!