Declarations in declare global can have export modifiers #64430

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   Needs InvestigationThis issue needs a team member to investigate its status.This issue needs a team member to investigate its status.

   on Sep 25, 2026
2. Ryan Cavanaugh (RyanCavanaugh)

   added this to the Backlog milestone on Sep 25, 2026
3. yksr-melt commented on Sep 29, 2026

   

   雪代 / Yukishiro (yksr-melt)

   on Sep 29, 2026

   Contributor

   More actions

   Short answer: export inside declare global isn't an error, and in the normal case it does nothing. Everything in a declare global block becomes global anyway, because the block is an implicit export context. This is the same in 6.0 and the Go port (7.1-dev).

   But it isn't completely ignored. There are two cases where it matters:

   1. Mixing exported and non-exported declarations is an error.

      declare global {
          export interface A { x: number }
          interface A { y: number } // TS2395: must be all exported or all local
      }

      getEffectiveDeclarationFlags deliberately skips the implicit-export treatment for global augmentation blocks. So this one check distinguishes export from no export, even though binding doesn't.

   2. An export declaration inside the block drops the non-exported members from the global scope.

      declare global {
          export interface B {} // becomes global
          interface C {}        // does not ("Cannot find name 'C'" elsewhere)
          export {};            // already TS2666
      }

   Compat: patterns like declare global { export const THREE: typeof _three; } show up in UMD-style typings (e.g. the checkMergedGlobalUMDSymbol test), so turning this into an error would be a breaking change.