Microsoft/TypeScript

Inconsistencies in ESM-style imports of accessibility-modified properties from CJS-exported classes

Open

#62,519 建立於 2025年10月1日

在 GitHub 查看
 (0 留言) (0 反應) (0 負責人)TypeScript (6,726 fork)batch import
BugDomain: ES ModulesHelp Wanted

倉庫指標

Star
 (48,455 star)
PR 合併指標
 (平均合併 6天 17小時) (30 天內合併 9 個 PR)

描述

Acknowledgement

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

Comment

Search terms

import AND class AND (protected OR private OR modifier)

Description

Given the following CJS module:

class X {
  public static a = 1;
  protected static b = 2;
  private static c = 3;
}
export = X;

then the behaviour of the static properties when using ESM-style imports is variable. For example,

import { a, b, c } from "module.cjs";

is permitted, but

import * as m from "module.cjs";
const { a, b, c } = m;

is not (m is an alias to the CJS export X, so this counts as a class property access and is subject to accessibility checks).

Protected and private class properties are also offered by tsserver for Intellisense suggestions when using ESM-style imports, but are obviously hidden when offering properties of the "namespace" object created by import * (since it's just an alias to the exported class), and do not appear in its keyof.

(The same would also apply if the CJS export were an instance of a class with accessibility-modified prototype properties, but exporting a class constructor is the more likely scenario encountered in the wild.)

Exposing intended-to-be-hidden properties in this way is almost always going to have been unintentional, and the alternative behaviour is fairly straightforward: add accessibility checks for NamedImports elements when the import target is a CJS export.

貢獻者指南