Closed jrandolf-2 closed 1 year ago
How important is this to you?
From my point of view this makes the spec harder to write and somewhat harder to read (the .within
isn't really adding any useful information for humans, so is basically just noise). I can see why you'd want it for a generic CDDL-to-interface conversion, but is there an alternate possibility of writing the logic to generate command name / event name enums as a special case?
The CDDL generator I created handles .within
strictly. In particular, it creates the type
export type RemovePreloadScriptCommand = {
method: "script.removePreloadScript" extends ScriptCommandMethod
? "script.removePreloadScript"
: never;
params: Script.RemovePreloadScriptParameters;
};
which validates that all commands have their methods defined in ScriptCommandMethod
.
This isn't really for generation. More about documenting the list of methods. Since everyone disagrees, I'll just close this.
I am in favor of improving the robustness of the generator but indeed this change adds redundancy (and maintenance difficulty) to the spec. If you happen to find another (simpler) way, feel free to send another PR.
The CDDL generator I created
Hey @jrandolf 👋 I am interested in your generator. I build one myself called cddl2ts
. Can you share anything about it?
@christian-bromann Sure! I think you are also on the Matrix group right? We can talk there!
This PR adds some helper types for understanding relevant method names for events and commands.
If this is merged, I'll add this for other domains as well.
Preview | Diff