Repository navigation
Invalid JavaScript output with re-exported unresolved import types (regression)Β #56445
Description
Activity
This is not a solution, but I would suggest using
export {} from ''signature next time.Hm, this seems tricky. I recall someone (maybe Anders Hejlsberg (@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, theexportat the bottom should be an error, at least underisolatedModules, becauseSomeTypemay also have a value meaning but TS can't know that without resolving the import.dragomirtitian commented
on Nov 17, 2023 ContributorAuthorMore actionsThis 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
verbatimModuleSyntaxwhich would flag this as an error, however we are not ready to enable that at present.dragomirtitian commented
on Nov 17, 2023 ContributorAuthorMore actionsHm, this seems tricky. I recall someone (maybe Anders Hejlsberg (@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, theexportat the bottom should be an error, at least underisolatedModules, becauseSomeTypemay 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.Titian Cernicova-Dragomir (@dragomirtitian) Yeah, I didn't mean to imply it wasn't problematic; it definitely is :) It just seemed tricky since
import typealso 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.
Bisects to #54799. Andrew Branch (@andrewbranch)
- addedFix AvailableA PR has been opened for this issueA PR has been opened for this issue
on Nov 17, 2023 andrewbranch commented
on Nov 17, 2023 MemberMore actionsItβs not a missing
isolatedModuleserror; itβs just an emit bug. This code is correctly transpilable without knowing how/whether'./type'resolves.Huh, it seemed weird to me that one could
import type { Class } from "foo"and then dotypeof Classbut still have the re-export elided (without being an error).- locked as resolved and limited conversation to collaborators
on Oct 22, 2025
π Search Terms
export type invalid JavaScript
π Version & Regression Information
β― Playground Link
Playground Link
π» Code
π Actual behavior
TypeScript will generate the following JS:
This JS is invalid since
SomeTypeis not defined. Basically theimport typeis removed, but theexportof 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.transpileModulesimilarly 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