Add an annotation that allows marking properties as required

[nschulzke]

This PR provides an annotation that allows marking properties that have default values as required in the TypeScript code.

The primary use case we have for this is for Read DTOs that have default values that are guaranteed to always be present by the time they reach the TypeScript code.

This is safe to use as long as encodeDefaults = true is set in the server's Json config. Otherwise all properties with default values should be considered optional.

[aSemy]

Thanks for the PR!

I think that the requirement for the annotation are quite niche. I would want to stick with the KxS principle of 'default properties means optional properties'.

That said, I think it would be really useful to have this in the docs. Then it provides a good example of how output can be customised. What do you think about converting it to a section in 'customising' docs?

[nschulzke]

I do think this is a common use case, but I can respect your decision to keep the core simple.

I don't believe there's any way to implement this using the existing hooks, because it requires being able to not just map from a descriptor object to a type like the existing descriptorOverrides do, but also being able to dynamically introspect the descriptor to access the annotations.

Can I submit a new pull request that allows providing an alternative TsElementConverter for use instead of TsElementConverter.Default, similar to how I can provide a TsSourceCodeGenerator?

[aSemy]

ah okay, it's been a while since I've worked on this lib, so I'll pick it back up and take a look at what's possible.

I don't believe there's any way to implement this using the existing hooks, because it requires being able to not just map from a descriptor object to a type like the existing descriptorOverrides do, but also being able to dynamically introspect the descriptor to access the annotations.

I've started work on a 'metadata extractor' that should be able to provide the serializer annotations at any stage in the process

Can I submit a new pull request that allows providing an alternative TsElementConverter for use instead of TsElementConverter.Default, similar to how I can provide a TsSourceCodeGenerator?

Yeah, give it a go! I think I did try to make all of the extractors/generators configurable, but it was difficult because of the caching I implemented.

[nschulzke]

I just learned while tinkering that kotlinx.serialization has a built-in @Required attribute that fills my needs, so this PR is definitely redundant. XD

I'll still take a look at making it possible to inject a TsElementConverter, because that would make everything completely configurable.