Recently encountered a peculiar scenario involving d.ts files and namespaces.
I have some d.ts files where I define and merge a namespace called PROJECT.
Take a look at how it's declared and automatically merged (across multiple files) below:
file1.d.ts ----- file2.d.ts ----- file3.d.ts
declare namespace PROJECT {
interface SOME_INTERFACE {
...
}
type SOME_TYPE = SOME_UNION_TYPE
// ETC
}
This PROJECT namespace is accessible from all files within my project. For example:
SomeComponent.tsx
const someVariable: PROJECT.SOME_INTERFACE = {
// ...
};
This behavior is entirely as expected.
The issue arose when I attempted to declare another namespace.
ADMIN_BLOGPOST.d.ts
import type { ACTION_THUNK_GENERIC } from "@hooks/useReducerThunk";
declare namespace ADMIN_BLOGPOST {
// HERE I DECLARE MULTIPLE TYPES
// AND ONE OF THE TYPES USES THE `ACTION_THUNK_GENERIC` TYPE, WHICH IS BEING IMPORTED HERE
type ACTION_THUNK = ACTION_THUNK_GENERIC<ACTION,GET_STATE>
}
Solely because of the top-level import type statement for ACTION_THUNK_GENERIC, my namespace is no longer automatically available.
VSCode now considers ADMIN_BLOGPOST.d.ts as a module, requiring me to explicitly import the namespace before using it, like so:
SomeComponent.tsx
import type { ADMIN_BLOGPOST } from "@src/types/ADMIN_BLOGPOST";
const someVariable: ADMIN_BLOGPOST.ACTION_THUNK
If I remove the top-level import of ACTION_THUNK_GENERIC from the ADMIN_BLOGPOST.d.ts file, then the ADMIN_BLOGPOST namespace becomes available without prior importation.
However, that import is essential to me as I require the ACTION_THUNK_GENERIC type to construct the non-generic ACTION_THUNK type.
Is there an alternative approach to achieve this, ensuring that my ADMIN_BLOGPOST namespace is accessible without the need for preemptive importing? In other words, how can I perform an import inside a d.ts file without converting it into a module?