Invalid JavaScript output with re-exported unresolved import types (regression)

[dragomirtitian]

🔎 Search Terms

export type invalid JavaScript

🕗 Version & Regression Information

• This changed between versions 5.1 and 5.2

⏯ Playground Link

Playground Link

💻 Code

import type { SomeType } from './type';

export { SomeType  };

🙁 Actual behavior

TypeScript will generate the following JS:

export { SomeType };

This JS is invalid since SomeType is not defined. Basically the import type is removed, but the export of the type was not.

🙂 Expected behavior

Type should be removed from export as in 5.1

Additional information about the issue

In the example above the source code has errors, so it could be argued that the output does not have to be valid. The issue was however discovered when using transpileModule . transpileModule similarly can't by design resolve the types and will preserve them in the output even though the types actually exist.

This is going to block us at Bloomberg from fully adopting TS 5.2 as we have workflows that depend on transpileModule

[spyhere]

This is not a solution, but I would suggest using export {} from '' signature next time.

[fatcerberus]

Hm, this seems tricky. I recall someone (maybe @ahejlsberg?) saying that import type { foo } actually imports both the type and value meanings of a symbol, and you just can't use it in emitting positions. This is so that you can still write e.g. typeof foo. So arguably, the export at the bottom should be an error, at least under isolatedModules, because SomeType may also have a value meaning but TS can't know that without resolving the import.

[dragomirtitian]

This is not a solution, but I would suggest using export {} from '' signature next time.

Sure, there are work arounds. The best one IMO (which we are working towards) is to use verbatimModuleSyntax which would flag this as an error, however we are not ready to enable that at present.

[dragomirtitian]

Hm, this seems tricky. I recall someone (maybe @ahejlsberg?) saying that import type { foo } actually imports both the type and value meanings of a symbol, and you just can't use it in emitting positions. This is so that you can still write e.g. typeof foo. So arguably, the export at the bottom should be an error, at least under isolatedModules, because SomeType may also have a value meaning but TS can't know that without resolving the import.

I mean it would probably be an error under verbatimModuleSyntax, but under our settings it does not produce any error and also generates invalid JS which is not ok.

[fatcerberus]

@dragomirtitian Yeah, I didn't mean to imply it wasn't problematic; it definitely is :) It just seemed tricky since import type also pulls in the value-space meaning which means the compiler must be able to resolve the import to know whether it should elide the re-export or simply error on it.

This should definitely error under isolatedModules and I consider it a bug that it doesn't.

[jakebailey]

Bisects to #54799. @andrewbranch

[andrewbranch]

It’s not a missing isolatedModules error; it’s just an emit bug. This code is correctly transpilable without knowing how/whether './type' resolves.

[fatcerberus]

Huh, it seemed weird to me that one could import type { Class } from "foo" and then do typeof Class but still have the re-export elided (without being an error).