Non-exported classes in type declaration files leaking value names

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.

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