Source Generator Hack - Write to disk instead of the syntax tree #102
Conversation
Removed the source code generation from context and instead write the generated code directly to a file. This change allows us to save the refit generated code as standalone files. This approach could be beneficial for future debugging and preview purposes.
A condition has been added to prevent generation of invalid filenames. Previously, the filename for generated source files would be .g.cs when the input file is only called ".refitter". Now, in this case, a default filename ("Refitter.g.cs") is used. This prevents errors when generating source files.
…iting" This reverts commit dc2a61c.
In this change, we've added a new Source Generator to generate Refit HTTP APIs interface stubs. This helps in consuming REST APIs by handling all the HTTP operations, allowing users to use them like ordinary C# interfaces. It benefits users with reduced boilerplate code and improvements in compile-time safety and IDE support.
The .gitignore file has been updated to include the 'src/Refitter.SourceGenerator.Tests/AdditionalFiles/Generated' path. This was necessary to ensure that Git doesn't track changes to these dynamically generated files, which can result in unnecessary noise in commits.
…enerated" relative to the .refitter file
…ll fail on first try
The function `context.AddSource` in `RefitterSourceGenerator.cs` has been commented out. The code was causing unnecessary repopulation of diagnostic reports leading to performance hits, hence it has been temporarily disabled for optimization till a long-term solution is found.
christianhelle
force-pushed
the
source-generators
branch
from
fabb1e1 to
d34131e
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
|
Btw.
This is by design, Source Generators are free to run concurrently and are not supposed to depends on other source generators output.
i guess by writing files you might actually needlessly trigger constant re-runs of source generators (due to new sources appearing), which may be especially bad for non |
|
Thanks for pointing this out @kirides I'm not entirely sure about the consequences of writing files but it seems that the files first appear at the end of the build. Refit at least doesn't pick it up when the files are just generated, you need to build again once the generated files appear Definitely some room for improvement in the Refitter soruce generator |
I simply can't, for the life of me, figure out how to trigger a 3rd party source generator from another source generator. So instead, as a bit of a dirty hack, the "rosyln source generator" writes to disk instead. The "source generator" will create a folder called Generated relative to the .refitter file and create a .g.cs (overrides existing files). This means that unless the .g.cs files are already on disk, the user might need to build twice. The first time experience will be quite crappy but the Refit interface will automagically update itself on build time
This sort of resolves #100 but it's still not a "real" fix
Here's are some short clips of how it behaves: