New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-exported classes in type declaration files leaking value names #32182
Comments
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: // ↓ OK!
/** @type {import('classes').A} */
let x;
// ↓ ERROR!
let y = x instanceof require("classes").A; The |
In a declaration file everything is implicitly exported. You can prevent that by adding |
Is that documented anywhere? That should really be documented.
This should also be documented. Does this syntax have a name?
@ajafff What do you mean that you can "export it as interface"? I see three options:
Here are the issues with those options:
In my opinion, the third option is the best of the bunch. Is there really no way to [meaning-full-y] export the |
TypeScript Version: 3.5.2
Search Terms: ambient module declaration export declare class type name
Code
In a file called
classes.d.ts
:In a file called
test.js
:In a file called
test.ts
:[NEW] Assumptions:
The following is a list of assumptions I had when originally opening this issue:
import
orexport
[on a top-level declaration], only explicitlyexport
ed declarations are visible externally.import
types (at least those that are used byexport
ed types.export class B extends A
exports the type namesA
andB
, even ifA
was not directlyexport
ed.#1
above) are only accessible if explicitlyexport
ed.These assumptions are the result of reading the documentation and working with declaration files. Note that the documentation does not mention:
export {};
syntax causes only explicitlyexport
ed 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
The text was updated successfully, but these errors were encountered: