TS 5.6 requires composite projects with noEmit to have fully accessible types, unlike 5.5

[Ambroos]

🔎 Search Terms

TS2742, TS7056, TS9006, TS4058, TS4023, noEmit, composite, 5.6

🕗 Version & Regression Information

• This changed between versions 5.5.4 and 5.6.2

⏯ Playground Link

https://github.com/Ambroos/ts-56-composite-project-noemit

💻 Code

file: Internal.ts

interface Internal {
    a: boolean,
}

export default function somethingInternal() {
    return {
        one: { a: true } as Internal,
    };
}

file: index.ts

import createInternal from "./Internal";
export const one = createInternal().one;

file: tsconfig.json

{
    "compilerOptions": {
        "composite": true,
        "noEmit": true,
        "strict": true,
    },
    "include": [
        "*.ts"
    ]
}

🙁 Actual behavior

In TS 5.6.2, run tsc and get error:

index.ts:3:14 - error TS4023: Exported variable 'one' has or is using name 'Internal' from external module "/Users/ambroos/Dev/ts-composite-5.6/Internal" but cannot be named.

3 export const one = createInternal().one;

This is the error in the sample project linked above (or created with the files from the code part). In our actual repo a large amount of new errors appeared that are related: TS2742, TS7056, TS9006, TS4058, TS4023.

🙂 Expected behavior

No errors, like 5.5.4 and older.

Additional information about the issue

This only happens in composite projects, even when not using --build. We have a large composite project, but the oldest parts of our code live in projects that don't emit since no-one is allowed to depend on them (they're apps that get built as-is).

In the past, when not emitting type declarations, it was OK to reference types that cannot be named, even in incremental compilation / composite projects. Now however it looks like because .tsbuildinfo is always generated, making code able to be emitted seems to have become required.

Maybe this is intentional, but it would be nice to still have some escape hatch for these types of composite project parts that don't actually need to emit declarations, they just need to be checked and transpiled.

[sheetalkamat]

Declaration error reporting if enabled is intended and was added as part of #59065

[Ambroos]

@sheetalkamat Is there a way to go back to the 5.5 behaviour with configuration? For these projects we don't really care about these specific errors that make it impossible to generate type declarations since nothing depends on them, and sometimes they're very hard to fix when we depend on external libraries.

[sheetalkamat]

Not really. Apart from disabling declaration there is no such option. Composite projects cannot disable declaration though

[Ambroos]

This feels like a bit of a difficult breaking change for 5.6 then that we have no easy way to recover from. It'd be nice to have a way to get back to this specific 5.5 quirk if that's possible.

For clarity, this error is fine (and expected) for 95% of the projects in our large composite project monorepo, but for some things it suddenly makes it impossible to bring in older projects that don't emit into our composite project (where they would start depending on newer, cleaner code). In 5.5 and older, setting noEmit on these projects was perfect: it makes it impossible to depend on them in a composite project (exactly what we want) and these types that cannot be named weren't a problem.

[Ayc0]

Hello 👋
I'm facing a similar issue for a codebase with more than 2500 packages with references & composite: true and this upgrade to 5.6 creates hundred of errors related to this Exported variable 'XXX' has or is using name 'YYY' from external module "ZZZ" but cannot be named.

But this change doesn't seem to be listed in https://devblogs.microsoft.com/typescript/announcing-typescript-5-6/ (or I may have missed it)

Also, a thing that is weird is that during the update, I was initially facing just a few errors. And as soon as I fixed those, hundreds of new TS4023/TS4058/TS9006 errors appeared

[s3xysteak]

It also happened to me TS2742: The inferred type of 'X' cannot be named without a reference to '.pnpm/Y'. This is likely not portable. A type annotation is necessary. with pnpm@9.10.0. It failed in ts@5.6.2 but worked well in ts@5.5.4