Recently, I made changes to my Next.js project by upgrading it to TypeScript. One of the modifications I made was updating my import alias from @/* to @*. Below is the new configuration in my tsconfig.json.
{
"compilerOptions": {
"target": "es5",
"lib": ["dom", "dom.iterable", "esnext"],
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"noEmit": true,
"esModuleInterop": true,
"module": "esnext",
"moduleResolution": "bundler",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"incremental": true,
"removeComments": true,
"noUnusedLocals": true,
"allowUnreachableCode": false,
"noUnusedParameters": true,
"noImplicitReturns": true,
"paths": {
"@*": ["./src/*"]
}
},
"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
"exclude": ["node_modules"]
}
In order to improve organization, I have structs containing custom types stored in a directory called /types. For example, User.ts contains:
export type TUser = {
_id: string;
name: string;
...
};
While importing components and modules works smoothly with the new alias like:
import Header from "@components/Header"
or
import { ConnectToDatabase } from "@modules/mongodb";
Importing custom types such as User using the same syntax results in a compile error:
import { TUser } from "@types/User";
The error can be resolved by importing the type as follows:
import { TUser } from "@/types/User";
Funnily enough, changing the folder name from types to something else also resolves the issue:
import { TUser } from "@typesd/User";
This behavior raises the question - why does this happen?