Summary

TS 5.x started to support new moduleResolution bundler and nodenext (or node16) which changes the behaviour of TS declaration files for arbitrary extensions like .json and .css.

By default, this import will raise an error to let you know that TypeScript doesn’t understand this file type and your runtime might not support importing it. But if you’ve configured your runtime or bundler to handle it, you can suppress the error with the new --allowArbitraryExtensions compiler option.

Note that historically, a similar effect has often been achievable by adding a declaration file named app.css.d.ts instead of app.d.css.ts - however, this just worked through Node’s require resolution rules for CommonJS. Strictly speaking, the former is interpreted as a declaration file for a JavaScript file named app.css.js. Because relative files imports need to include extensions in Node’s ESM support, TypeScript would error on our example in an ESM file under --moduleResolution node16 or nodenext

By enabling the TS allowArbitraryExtensions setting, declaration files can be imported but are required to follow the {file basename}.d.{extension}.ts pattern which is not supported yet by API-Extractor.

Repro steps

1. change the moduleResolution to bundler and allowArbitraryExtensions to true in the tsconfig.json file.
2. convert any .json.d.ts file extensions in the repo to .d.json.ts

Expected result:

API extractor to not throw warnings or errors

Actual result:

API extractor shows a ae-wrong-input-file-type warning for the files with .d.json.ts extension.

Details

This can likely be fixed by updating the below regex with the new pattern.

(unrelated to API extractor, but I also suspect the heft-sass-plugin is impacted since it generates css.d.ts files)

Standard questions

Please answer these questions to help us investigate your issue more quickly: