Import and export TS types and interfaces in Next.js app don't needed anymore?

[AngelinaPlax]

Summary

Hello!
I study Next.js and create an app based on Next.js and TypeScript.
I don't add import and export to my TS interfaces and types, that are stored in another folder, and it works!
Can I don't use import for TS interfaces and types?
(But if I add export to my interface, error will appeared in file, where I use this interface)

If I have this code in types.ts file:

interface IAboutIdProps {
  params: {
    id: string;
  };
}

and this code in my page.tsx file:

import { shops } from "@/app/constants/constants";

export default function AboutId({ params: { id } }: IAboutIdProps) {
  const shopInfo = shops.find((shopInfo) => shopInfo.id === id);
  return (
    <h3>
      Something about {shopInfo?.name || "This shop does not exist in DB"}
    </h3>
  );
}

It will work.
But when I do this way:

export interface IAboutIdProps {
  params: {
    id: string;
  };
}

my page file will have issue 'Cannot find name 'IAboutIdProps''

Could you please explain me why it works like that?

Additional information

No response

Example

No response

[devjiwonchoi]

Did you import the types file to the page?

import { shops } from "@/app/constants/constants";
import { IAboutIdProps } from "@/app/types";  // location of the `types` file.

export default function AboutId({ params: { id } }: IAboutIdProps) {
  const shopInfo = shops.find((shopInfo) => shopInfo.id === id);
  return (
    <h3>
      Something about {shopInfo?.name || "This shop does not exist in DB"}
    </h3>
  );
}

[AngelinaPlax]

I did it, of course.
Question about why my application works even if I do not add imports and exports for my TS types

[icyJoseph]

This is an obscure TypeScript feature. If a file has no import/export, then it is not a module, so it becomes global.

For example:

// import type {GetServerSideProps} from 'next'

interface Foo {
  bar(): void;
}

type Baz = {
  fizz(): void;
};

As long as the top line is commented, Foo and Baz will be visible from other files. The moment you uncomment that, this becomes a module and both Foo, and Baz, become private instances of the module. Likewise, the moment this file does an export, it turns into a module too.

This sort of reliance on global, or magically available, types, is anti-pattern that'll bring lots of chaos to your codebase. Avoid it.

--isolatedModules

https://www.typescriptlang.org/tsconfig#isolatedModules

What is throwing me off here, is that isolatedModules should forbid this, but it is not 😅 😮 - Perhaps I am missing something else, but it should be like, parsers, should be able, by looking at a single file, to get all type information they need to compile that file, and with "magically available" types that's not possible.

This is what I'd expect:

'foo.ts' cannot be compiled under '--isolatedModules' because it is considered a global script file. Add an import, export, or an empty 'export {}' statement to make it a module.ts(1208)

For a foo.ts file:

function foo(){}

[email protected] (verified in 4.9.5 too)

It might be a TS issue... now that I've downgraded from 5.x.x to 4.x.x, I see the error I'd expect:

I'll go through the TS release logs and see if there's something mentioning this change in behaviour.

For completeness sake here's the entire file from the screenshot:

// import type {GetServerSideProps} from 'next'

interface Foo {
  bar(): void;
}

type Baz = {
  fizz(): void;
};

function foo() {}

[icyJoseph]

Alright, managed to test up to [email protected] and it works up till then. Tested with [email protected] and it is starts to show this behavior.

[icyJoseph]

Alright @AngelinaPlax according to this issue: microsoft/TypeScript#53683, it is working as expected 😅 I wonder if there's a combination of flags to still trigger a compilation error.

[icyJoseph]

One thing you can do now is add:

"moduleDetection": "force",

To your tsconfig file, and that'll forbid the behavior you observed @AngelinaPlax

[AngelinaPlax]

Many thanks!