Rename modules to avoid aliasing

[giacomocavalieri]

Right now all .gleam files created by squirrel are called sql.gleam. This is not the best since once will most likely have to alias those in order to use functions coming from multiple modules. It would be better if squirrel called those <name>_sql.gleam where name is the name of the parent folder of the sql folder the queries are taken from. For example if I have src/user/sql/*.sql I'd like the generated file to be src/user/user_sql.gleam, if the sql directory is already at the top level (src/sql) then we'd have to stick to just sql.gleam.

This would also require updating the documentation describing where squirrel puts the generated code!

[ross-byrne]

I'm working on this and have a solution working, I just need to handle testing.

What are your thoughts on testing file generation? After making this change, all the current tests passed. So there is a bit of a gap I'd like to fill.

I'm planning on adding unit tests but I've also built a minimal project locally that I'm using to test the file generation. Thinking out loud here, but maybe we could add an examples/fixtures testing folder with a test project(s) . Then run some tests against it some how. Either integration tests or maybe something in a GitHub Action?

[giacomocavalieri]

I'm not really sure how to go about this, if you want to open a PR with what you have it would be great! So I can have a look and give you a more informed suggestion

[ross-byrne]

Sure, I just need to update the docs and then I'll open a PR. I wont get around to it until later today thought

[giacomocavalieri]

No rush at all! Take all the time you need ☺️

[ross-byrne]

@giacomocavalieri just an update on this: I submitted my pr, I just forgot to update here

[ToddG]

When can this get merged, it'd be useful to me 👍

[giacomocavalieri]

Hello! Since this would be a breaking change and require a new major release I've decided to wait a little longer and experiment a bit more with Squirrel before going for it. Thanks for the patience, but it might take a while!

[adjohnston]

Just to add to the disucssion, I was playing around with Squirrel recently and was implementing some types from the OCPI spec. As an enum value, UNKNOWN appears quite often, as an example, in the location's LocationType and EVSE's Status types both include UNKNOWN. I would hope this change fixes the issue of having duplicate definitions in a single module.