Repository navigation
Non-exported classes in type declaration files leaking value names #32182
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:
- Type Declaration Files work like modules: once you use
importorexport[on a top-level declaration], only explicitlyexported declarations are visible externally. - Type names declared in a Declaration File are always accessible via
importtypes (at least those that are used byexported types.- E.g.
export class B extends Aexports the type namesAandB, even ifAwas not directlyexported.
- E.g.
- Value names declared in a module-style Declaration File (see
#1above) are only accessible if explicitlyexported.
These assumptions are the result of reading the documentation and working with declaration files. Note that the documentation does not mention:
- All declarations in a declaration file are implicitly exported.
- Special [and undocumented?]
export {};syntax causes only explicitlyexported 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:
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
Activity
ericdrobinson commentedon Jun 29, 2019
Without support for this it is extremely difficult to model a module that has a private base class with many public subclasses.
The following is a snippet of JavaScript:
The
importtype currently works as expected. 👍The
instanceofline beneath it does not report the expected error. 👎ajafff commentedon Jun 30, 2019
In a declaration file everything is implicitly exported. You can prevent that by adding
export{};.With that change you can also no longer use
Aas type. To fix that you need to export it as interface.ericdrobinson commentedon Jun 30, 2019
Is that documented anywhere? That should really be documented.
This should also be documented. Does this syntax have a name?
Klaus Meinhardt (@ajafff) What do you mean that you can "export it as interface"?
I see three options:
Aclass toAClassand export a type:export type A = AClass;.Aclass toAClassand export an interface:export interface A extends AClass {}.Here are the issues with those options:
class, the type shown on hover reads as the resolvedAClass. Which is not the desirable information to convey.interfacerather than aclass.In my opinion, the third option is the best of the bunch.
Is there really no way to [meaning-full-y] export the
typeof a class rather than both itstypeandvalue?[-]Non-exported classes in type declaration files leaking names[/-][+]Non-exported classes in type declaration files leaking value names[/+]