Any way to use JSImportGenerator in another generator library?

[elringus]

I'm currently figuring how to port my JS interop library to the new JS iterop API introduced in .NET 7 and have an issue with the source generators used there.

I'm using source generator myself to generate the JS bindings based on C# interfaces, but the new interop also uses a generator for [JSImport]-attributed methods. Since it's not possible to chain source generators, I wonder if it's possible to somehow use JSImportGenerator in my custom generator library? I wasn't able to find associated package on nuget and the project itself doesn't seem to be designed to be used as a library.

Is this by design that source generators in general are not meant to be chained or consumed by other generators or I'm missing something?

[jkotas]

cc @pavelsavara

[En3Tho]

I think it is by design, yes. Mainly because source generators were never able to see the output of each other as that would certainly create more problems than solve.

Now the "chaining" can happen if source generator itself is designed as 2 parts: Library( analyze stage, IR stage) and Emitter (write text based on IR).

I don't think Emitter can be generally reused as it is just "write some text to the output based on some IR". Obviously whacky string manipulations can come to mind but I don't think it is a good way.

But I think the analyze and IR can be reused as it is just a library basically. It is all based on the design of a particular SG.

[pavelsavara]

For generating JS/TS, there is relevant discussion in dotnet/roslyn#57608, so far it seems to say use MSBuild target and run Roslyn again and read the AST. I didn't explore deeper how to do that. Small demo would be appreciated.

[elringus]

Hey, Thanks for chiming in! My issue is not with JS/TS but with C# code generated by JSImportGenerator used in the new JS interop. As I'm using a source generator myself to generate bindings based on C# interfaces, I can't emit methods with the new JSImport attribute, as they are partial and subject to source generation themselves. This was not an issue with the old interop layer, as it didn't use source generators.

I wonder what options do I have, beside replicating the whole JSImportGenerator behaviour. With generators chaining not possible, I hoped that maybe JSImportGenerator (or a subset of it, as @En3Tho suggested) could be published as a package to be utilized in other source generators as a library.

[pavelsavara]

Making NuGet package out of generators would force us to keep backward compatible API. And possibly generate more stable code which could be wrapped/extended. I think we currently don't have bandwidth for that in my team.

LibraryImport generator probably has the same characteristics, right ?
@jkoritzinsky what do you think ?

[elringus]

That's understandable. Ideally, source generators would allow chaining/cascading; judging by dotnet/roslyn#57239 this had been an issue since the generators were originally introduced and is now spreading across the runtime.

[jkoritzinsky]

We have long term plans to ship the core of the interop generators as a library. We can include the JS generator infra as well. Probably .NET 9 at the earliest though.

[elringus]

By the way, @pavelsavara I've just dived in to the new dotnet.js API and it's amazing! Absolutely solves all the issues I had when tried to use it in .NET 6, like embedding the binaries, managing exports/imports and overriding the config. Thank you very much for the effort!

[pavelsavara]

Heads up. We will change the layout/location of the JS files and config file in Net8 to streamline some of the Blazor use cases. The TS API keeps quite stable in Net8.