Preserve narrowing in closures for imports that resolve to `const` variables

Abierto
  • ¿Algo no está bien?
#64,959 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, typescript
Área
compilers

Línea de trabajo

Start with the prototype commit linked in the issue and the Go checker's checkIdentifier and isConstantVariable logic. Review the compiler tests and baselines affected by the prototype, then add coverage for named, renamed, default, and re-exported imports that resolve to const bindings. Done means closure narrowing matches local const behavior while the listed exclusions and compatibility cases retain their expected diagnostics.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Suggestion
Acknowledgement
  • I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.
Comment
Suggestion

A const keeps its narrowing inside callbacks. The same value imported from another module doesn't:

// @filename: a.ts
export const user: { name: string } | undefined =
  Math.random() > 0.5 ? { name: "Ann" } : undefined;

// @filename: main.ts
import { user } from "./a";

if (user) {
  user.name;                      // ok
  setTimeout(() => user.name);    // error TS18048: 'user' is possibly 'undefined'
}

const local = user;
if (local) {
  setTimeout(() => local.name);   // ok
}

Bug Workbench

TypeScript already keeps narrowing in closures for const variables and unassigned parameters (#10357), and for closures created after a variable's last assignment (#56908). Imports can be narrowed too (#16658), but in a nested closure that narrowing is lost, even when the import resolves to a const. This proposal extends the existing const rule to that case. It doesn't ask TypeScript to reason about when callbacks run (#9998).

const keeps its narrowing in closures because nothing can reassign it between the check and the call. The same is true of these imports: in an ES module, an import is an immutable binding[^1] to the exporter's binding, a const binding is immutable too[^2], and writing to either throws at runtime[^3].

The prototype covers named and renamed imports, default imports of a const (export default user), and re-export chains, including export *. Unchanged:

  • export let: the exporting module can still reassign it;
  • ns.user after import * as ns: a property access, not an identifier;
  • default-exported expressions (export default (expr)): they don't resolve to a const;
  • imported function and class declarations.
Motivating Example

Checking an imported constant now works inside callbacks, the same way it does for a local const:

import { logger } from "./logger"; // export const logger: Logger | undefined

if (logger) items.forEach(item => logger.info(item)); // no more "possibly 'undefined'"
Use Cases
  1. Module-level values that may be absent: optional config, feature-flagged services (export const analytics = enabled ? createAnalytics() : undefined), DOM lookups. They get checked once and then used in .map, setTimeout or an event handler.
  2. Removing workarounds: today people copy the import into a local const or add ! just to get past the checker. The copy is boilerplate, and ! also hides a real undefined later.
  3. Generated code. vue-tsc turns templates into TypeScript, where event handlers are arrow functions inside narrowed blocks, so imported constants started reporting errors there (vuejs/language-tools#6237). The proposed fix works around it in the generated code by unwrapping the reads inside closures (vuejs/language-tools#6238). For imported constants, TypeScript could keep the narrowing itself.
Prototype

The prototype was written with the help of Claude Opus 5.5 and reviewed with GPT-6 Astra.

I tried this in the Go checker (main at 8d9b6da99). JavaScript emit is unchanged. The change is one condition in checkIdentifier plus a helper (commit with the change and the test):

func (c *Checker) isConstantVariableOrAliasOfConstantVariable(symbol *ast.Symbol) bool {
	// resolveAlias stops at a re-export merged with a type of the same name, so keep resolving
	// until a symbol has a value meaning of its own
	var seenSymbols collections.Set[*ast.Symbol]
	for ast.IsNonLocalAlias(symbol, ast.SymbolFlagsValue) {
		target := c.resolveAlias(symbol)
		if target.Flags()&ast.SymbolFlagsAlias != 0 {
			if target == symbol || seenSymbols.Has(target) {
				return false
			}
			seenSymbols.Add(target)
		}
		symbol = target
	}
	return c.isConstantVariable(symbol)
}

The change leaves the existing compiler baselines unchanged, and benchmarks on Vuetify and vuejs/core showed no statistically significant change in check time. The same check in the JavaScript checker gives identical diagnostics on eight open-source Vue projects (Nuxt, Vuetify, VueUse and others) before and after.

Compatibility: stronger narrowing can introduce diagnostics and change inferred types in previously accepted code, including types in emitted declarations. For example, given an exported const mode: "a" | "b":

import { mode } from "./a";

if (mode === "a") {
  [1].map(() => mode === "b"); // new TS2367
  const modes = [1].map(() => mode); // now "a"[], previously ("a" | "b")[]
  modes.push("b"); // new TS2345
}

These are the same diagnostics the example produces today with a local const mode instead of an import. The second one can break otherwise valid code; annotating the array (const modes: ("a" | "b")[]) keeps the old type.

CommonJS output is different: an import is read as a property (a_1.user), and other code could overwrite it. TypeScript already makes the same assumption in the exporting module: in a.ts, if (user) setTimeout(() => user.name) compiles to exports.user in both places and keeps its narrowing today. The change extends it to the importing side.

If this direction sounds right, I can open a PR with the change and the test.

Optional extension

Aliased conditions have the same gap for imports, even without a closure: const ok = typeof user === "object"; if (ok) user.name errors, unlike with a local const. Applying the same alias check in isConstantReference fixes it, and the existing baselines stay unchanged. I can include it in the same PR, or send it separately if you prefer.

[^1]: ECMA-262, CreateImportBinding: an import "creates a new initialized immutable indirect binding" that resolves to the exporter's binding.
[^2]: ECMA-262, InitializeEnvironment for Source Text Module Records: a module-level const is created with CreateImmutableBinding.
[^3]: ECMA-262, SetMutableBinding: writing an immutable binding throws a TypeError in strict mode code, and module code is always strict.

Lenguaje dominante
Go
Estrellas
112k
Forks
15.4k
Merge medio
3 d 6 h
PR fusionados (30 d)
136

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/TypeScript

Todos los issues de microsoft/TypeScript

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.