disneystreaming
(sbt) Files not removed on subsequent codegen run
To reproduce:
- Generate code for any shape
- Rename the shape
- Generate code again
- Look at the output
Example:
https://github.com/disneystreaming/smithy4s/assets/894884/687fc3df-d561-44f5-9dd9-a9e16de3be42
Happens in 0.18.18.
I'm thinking to delete previously generated files in sbt only, because:
- CLI: people are very likely to use
.as the target which could very easily turn into an annoying experience - Mill: we generate to a task-specific path that gets cleared on invalidation, so this shouldn't be happening in the first place
I'm not too sure what kind of impact deleting would have, which is why I elected not to do it in the first place. In the grand scheme of things it shouldn't matter too much, because SBT expects the sourceGenerator task to return the list of all files that were generated :
https://github.com/disneystreaming/smithy4s/blob/b96f736b0ea8a01447d91d6c4a2204b0be980320/modules/codegen-plugin/src/smithy4s/codegen/Smithy4sCodegenPlugin.scala#L291-L293
So maybe this impacts the editor, but I'm not sure it's actually a good idea to clean up before regeneration.
I think it does have impact, because your app code may still have references to the old files, and it'll compile locally but e.g. won't compile anymore when you push changes and CI runs on them.
If we can access the list of previously generated files, removing them is IMO the right thing to do, but I suppose we should see what other codegens do, like scalapb.
and it'll compile locally
What I'm saying is that it won't compile locally, at least I don't think it will compile in SBT.
oh I see what you mean - the files not on the list shouldn't be included in the compilation, so only the IDE will see them, at least (I guess) until you re-import your project.