deno doc: Blob interface is not exposed

[ry]

> deno doc https://github.com/denoland/deno/releases/download/v0.40.0/lib.deno.d.ts  | rg Blob
const Blob: { prototype: Blob }

The interface associated with that type is not in the documentation:
https://github.com/denoland/deno/blob/v0.40.0/cli/js/lib.deno.shared_globals.d.ts#L871-L884

This is a common pattern in d.ts files, using a const variable with a set prototype and an interface.

[lucacasonato]

Its not exposed because its not declared or exported

[ry]

Its not exposed because its not declared or exported

I see. I guess the question is if we should support having doc items that are not declared/exported.... This is the pattern that TS uses:

https://github.com/microsoft/TypeScript/blob/f31b5a278f03b2e2d2713ed64230f853ae6b4545/lib/lib.dom.d.ts#L2536-L2549

[bartlomieju]

This problem is also manifested when there's a function with a return type that is not exported - just a string name is visible, can't link to it. Documenting full module is not harder than current setup and would allow more flexible presentation. After all web interface can have some toggles to show/hide not exported stuff

[lucacasonato]

That wouldn't fully solve the issue either as it doesn't make sense for re-exports. Also I think displaying everything is fundamentally wrong, even with a toggle, because the end developer can not use those functions, interfaces, classes, ect because they are not exported or declared. godoc also doesn't display non exported nodes.

I also don't quite understand what that pattern is meant to describe. Is that just a different way of writing this?
```ts
declare class Blob {
constructor(blobParts?: BlobPart[], options?: BlobPropertyBag);

readonly size: number;
readonly type: string;
arrayBuffer(): Promise;
slice(start?: number, end?: number, contentType?: string): Blob;
stream(): ReadableStream;
text(): Promise;
}

[ry]

I also don't quite understand what that pattern is meant to describe. Is that just a different way of writing this?

I don't really understand the pattern either - it does seem the same as a class declaration - but it's used often in TS, and it seems we should try to work with them.

Also I think displaying everything is fundamentally wrong, even with a toggle, because the end developer can not use those functions, interfaces, classes, ect because they are not exported or declared.

I guess I agree with that too. Hm.

[kitsonk]

I don't really understand the pattern either - it does seem the same as a class declaration - but it's used often in TS, and it seems we should try to work with them.

It is part legacy, part the way the Web IDL works. TypeScript predates ES6, so class technically wasn't there, and the Web IDL technically splits the constructor function from the prototype, so it is easier to translate. Also interfaces can always exist in .ts or .d.ts without implementation, where class in a standard .ts file can't just be the type information, it has to have the implementation.

A class always has two interfaces anyways, and most of the time they are merged, but they can be separated (Foo is the instance interface and typeof Foo is the constructor interface). The generated lib files always have them explicit and never use the class keyword, but create the FooConstructor interface.

I have been working on re-doing events to be more maintainable, and I have started to use class in dom_types.ts (as well as moving it back to being a dom_types.d.ts to ensure we don't have runtime code in there).

Also I think displaying everything is fundamentally wrong, even with a toggle, because the end developer can not use those functions, interfaces, classes, ect because they are not exported or declared.

I guess I agree with that too. Hm.

TypeScript will allow use of symbols that are referenced but not exported, I think it used to be a bit more strict about that. I wouldn't document everything, but it does feel that if there is an export, it should include all of its dependent symbols... (or we need something to warn us that it is referencing an unexported type.

[bartlomieju]

No longer relevant