`Blazor` JavaScript object and related type definitions should be available (`@types/blazor`, `@types/dotnet`)

[yugabe]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

For developers, knowing the shape of the Blazor global JavaScript object would be a great help. It wouldn't just help with stricter type checking, but also could help exploring the APIs and could serve as a point of initial documentation. The shape of the object can be more easily described programmatically than via documentation (the ASP.NET Core Blazor startup page describes the object in detail anyways, but doesn't include or describe all possible options).

Currently, only one slightly relevant, community-managed package exists in the form of @types/blazor__javascript-interop, however, it only includes the few JS interop methods and not the main Blazor object itself.

Describe the solution you'd like

Seeing as the source of the _framework/blazor.*js files is already in TypeScript, it would be trivial to generate the type definitions (.d.ts files) for a DefinitelyTyped package. The main entry point of the code can be found in the https://github.com/dotnet/aspnetcore/blob/main/src/Components/Web.JS/src/GlobalExports.ts file.

However, it would be even better if the relevant exports were documented with JSDoc comments so IntelliSense would help describing the (public) APIs, and possibly excluding the "internal" APIs (these are currently available at runtime, and by default, would be included in the automatically generated type definitions as well).

It seems trivial that generating the type definition package can be included as a deployment step for the framework, however, giving an initial version of the package for .NET 8 would greatly help developers as well.

Additional context

• Publishing the definitions would also help developers when the public API shape would change, as the breaking APIs would become compile-time errors (or at least linting errors). However, keeping the version of the type definitions and the framework in sync would still need to be manually done by the user.
• It seems trivial that using the Blazor APIs in JavaScript would pose a dependency on various other .NET features as well, like the JS interop APIs, the DotNet object and so on (see https://github.com/dotnet/aspnetcore/tree/main/src/Components/Web.JS/%40types/dotnet). It's worth considering how these are related and if any of these should be published together.
• The current workaround is that the user has to either describe the shape of the object based on the documentation or the code. Both pose the problems that they get out of sync and have to be maintained manually and individually.

[javiercn]

@yugabe thanks for contacting us.

This is a dupe of #10124

Please upvote that instead.

[yugabe]

Thanks @javiercn, I saw that issue, but that is related to how the blazor.*.js runtime files could be published to npm. This fr is not for the runtime, only the type definitions. I'd expect the latter to be significantly easier to implement, and they solve different problems.

[yugabe]

I just published a prototype that could help others having similar pain points as I did with type information not being available. See https://github.com/podNET-Hungary/blazor-typings

If anyone would like to make a version for https://github.com/DefinitelyTyped/DefinitelyTyped, feel free to go for it.