Change generated code based on the project's dependencies

[giacomocavalieri]

As Inoas pointed out on Discord, it would be nice to have a way to avoid having a hard dependency on any specific library for supported types (eg youid for uuids); otherwise we'd end up having a set of blessed squirrel packages.

Louis proposed that squirrel could generate code for the specific dependency you have: let's say you have another uuid library as a dependency of your package, squirrel could detect it and generate code appropriate for it instead of defaulting to youid

[sporto]

hmm, maybe we could have an approach where this lib doesn't depend on any of these other libs. Couple of reasons:

• Managing peer depenedencies in Gleam atm is quite difficult, when you have a version conflict, the compiler helps very little
• I can see people using more than one lib for ids, e.g. the library https://github.com/rvcas/ids can generate ulids, ulids can be stored in PG in the native uuid type.

Maybe an approach could be:

• by default squirrel would return its own UUID type, people can map that to other lib
• the generator could generate advanced functions, which will require the user to provide the decoders. e.g. I want a uuid to be decoded to a ulid. I want a bitarray to be decoded to my custom type.

[lpil]

To me it seems the point of this library is a large part to remove conversion boilerplate, so it would be a shame to add it back.

Selecting based upon dependencies may not always work, but I think it would be vast majority of the time, so there could be a lot of value there.

Another option may be to have some explicit configuration in gleam.toml.

If there's multiple dependencies that could be selected from they'll need to no longer be dependencies of Squirrel to avoid pulling in unused deps, so Squirrel would need to implement checking the project deps and erroring if the package required by the codegen is absent or of an unsupported version.

[giacomocavalieri]

To me it seems the point of this library is a large part to remove conversion boilerplate, so it would be a shame to add it back.

Totally agree! I think having some sort of configuration in gleam.toml could be the way to go

[lpil]

Either way I think it'd be good to wait until users feel some irritation with the current system before we expand it, so we know more about the situation.

[giacomocavalieri]

100%!