Open mike1o1 opened 5 years ago
And dedupe signalr if you are additionally using that so its not double included.
Is this planned to be implemented anytime soon? This also applies to Web Assembly. I would like to bundle all TS/JS using webpack, including _framework/blazor.webassembly.js It would be convenient to have it available as an npm package.
@danroth27 what're your thoughts on this?
@javiercn Is there a better way to integrate the Blazor framework scripts into an asset build pipeline without us having to release them to NPM?
@danroth27 we might be able to concoct something, but tbh the proper way to do this is to publish some sort of package to the npm registry, at the very least with the typings.
For type definitions, see also: https://github.com/DefinitelyTyped/DefinitelyTyped/pull/42392.
Note as part of this task, we may want to consider adding official docs on how to use TypeScript with Blazor, environment/project configuration, etc.
cc/ @guardrex. No action now but just so it's on your radar 😄
If it becomes possible to get the JS code from a different source, we should add some kind of exact version match checking at runtime, blocking the app from starting unless it's exactly correct. Until now we've never had to deal with people using the wrong version of blazor.webassembly.js
for their .NET runtime, and it would be good to avoid that becoming a possibility.
For JSInvokable marked stuff, what about generating jsdoc and typescript definitions?
@unicomp21 Thanks for the suggestion! Could you please open a separate GitHub issue with this idea and your thoughts on how it should work? This issue is really tracking something different.
@danroth27 thx! https://github.com/dotnet/aspnetcore/issues/40499
Thanks for contacting us.
We're moving this issue to the .NET 7 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
Using https://github.com/dotnet/aspnetcore/issues/40499 to track the type definition publishing.
Thanks for contacting us.
We're moving this issue to the .NET 8 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Thanks for contacting us.
We're moving this issue to the .NET 9 Planning
milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.
Manually created TypeScript type definitions for the Blazor
API: https://github.com/podNET-Hungary/blazor-typings
I'm working on implementing some server-side Blazor components, but I have a lot of other Javascript functionality on the page. I would like to be able to include the needed
blazor.server.js
file in my webpack build process, instead of having to embed it directly on the page. This way all of the Javascript for my application gets included in one file.I would like to be able to bundle
blazor.server.js
into my webpack build, by either accessing it through NPM or being able to link to it directly. However, according to aspnet/AspNetCore.Docs#12358 this is an embedded resource in the middleware, so I'm not sure how I can access it and include it in my build.