microsoft / microsoft/TypeScript

Non-exported classes in type declaration files leaking value names

Open
#32,182 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Docs
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
2d 4h
Merged PRs (30d)
132

Description

TypeScript Version: 3.5.2

Search Terms: ambient module declaration export declare class type name

Code

In a file called classes.d.ts:

declare class A {}
export declare class B extends A {}

In a file called test.js:

let a = require('classes').A;

In a file called test.ts:

import { A } from './types/classes';

[NEW] Assumptions:
The following is a list of assumptions I had when originally opening this issue:

  1. Type Declaration Files work like modules: once you use import or export [on a top-level declaration], only explicitly exported declarations are visible externally.
  2. Type names declared in a Declaration File are always accessible via import types (at least those that are used by exported types.
    • E.g. export class B extends A exports the type names A and B, even if A was not directly exported.
  3. Value names declared in a module-style Declaration File (see #1 above) are only accessible if explicitly exported.

These assumptions are the result of reading the documentation and working with declaration files. Note that the documentation does not mention:

  1. All declarations in a declaration file are implicitly exported.
  2. Special [and undocumented?] export {}; syntax causes only explicitly exported declarations to be available by consumers of the declaration file.

I list them here to provide context for the Expected Behavior section.

Expected behavior:
In both cases , an Error that name 'A' could be found in module 'classes'.

I expect in this case that TypeScript is capable of resolving the following from the declaration file:

  1. The Value "B".
  2. The Types "A" and "B".

In other words, I should be able to use import types to resolve class A, but attempts to use them should fail.

Actual behavior:
No compiler error in either case. TypeScript-powered IDEs (e.g. VSCode) happily show that the full non-exported class A is available.

In short, a non-exported, declared class should resolve in the same way as an interface.

As things stand today, TypeScript erroneously resolves the Value "A".

Playground Link: NA

Related Issues: NA

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the behavior using the classes.d.ts, test.js, and test.ts examples in the issue, then trace declaration-file module and symbol resolution in the TypeScript compiler. Done means the non-exported class A is not exposed as a value while the type references required by exported class B continue to resolve, with regression coverage for both examples.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.