arktype•5mo ago

Adding comment to object key

Hello! What would be the right way to add comments to an object's key, like you do with /** */? I tried this, but it didn't work:

output: type({
  /** Image id */
  id: type('string').describe('Image id'),
})

output: type({
  /** Image id */
  id: type('string').describe('Image id'),
})

22 Replies

Unknown User•5mo ago

Message Not Public

PIatOP•5mo ago

Thank you! Good to know 👍

Dimava•5mo ago

Hmm @ssalbdivad looks like a regression since v1

ssalbdivad•5mo ago

@Dimava I remember you had opened an issue related to this but I know in the general case it is not possible as @AlexWayne mentions, especially given the addition of parsed syntax for e.g. index signatures within keys

Dimava•5mo ago

ik general case is not possible but non-optionals did work well type.for (what was it again? I still forget it every time) may be better for those

ssalbdivad•5mo ago

declare.type If it is possible to implement a solution that preserves them for required keys without sacrificing perf and ideally without duplicating a ton of code I would be open to merging that, it's just not something I want to commit to broadly since TS's rules around it aren't necessarily clear or well-documented either

Dimava•5mo ago

IIRC there was only a single working rule and it was "[K in keyof T as X] should use clean K in X when required " Gonna check how your code works

ssalbdivad•5mo ago

Yeah it has to be a homomorphic mapped type but you can see why I'm not just not very keen on the idea of making guarantees around behavior like this based on the extent of what TS has officially guaranteed about it

Dimava•5mo ago

This should work, how do I bench

ssalbdivad•5mo ago

pnpm benchObject My intuition is that is not great since it adds an extra intersection to every object type And that EscapeToken comparison is not trivial not always correct (though it would still be an improvement to get it most of the time)

Dimava•5mo ago

+2.5%

ssalbdivad•5mo ago

That's not bad, I'd want to do some more testing though since those aren't really comprehensive enough on their own to give me a lot of confidence about a change of this scope. What about pnpm attest stats before and after the change

Dimava•5mo ago

ssalbdivad•5mo ago

Yeah that's less encouraging plus what are the errors

Dimava•5mo ago

Okay, 4519 is my best result That's 7.6% up

ssalbdivad•5mo ago

Feels like a lot for something most people won't notice

Dimava•5mo ago

Yup

ssalbdivad•5mo ago

I think the way I might consider doing this is to diverge from TS and have index signatures from literal values like {"['foo' | 'bar']": "string"} inferred as optional instead of required. If I did this, I could do something like what you suggest without creating an additional intersection or adding more conditional checks Based on the implementation of Record, this would also make Record<"foo" | "bar", string> optional which differs from TS as-is, but I do think it actually makes more sense that way, and you could always add a Required if you want all the props You'd never be able to directly specify optional keys and have JSDoc preserved, but if I allow the partial chainable to accept args for each key to make optional, there might be a viable path to preserving JSDoc for people who need it without affecting perf

Dimava•5mo ago

It'd be possible if there was ".optional()" same as in Zod, which would make |undefined in sole type but use ? in object Typings for that do seem heavier tho

ssalbdivad•5mo ago

It's not the typings I'm worried about- I already have to check for this kind of thing with default values

Dimava•5mo ago

As that's value-dependent key typing

ssalbdivad•5mo ago

The model is fundamentally wrong Because .optional() values become kind of meaningless outside an object but there's nothing I can do stop them being chained that way in any context I would still consider it, same with .default, but the main motivation for not having that exist isn't the type perf it's the fact that it optionality genuinely belongs to the key not the value I guess it's kind of doomed anyways because there will still be required keys that are parsed e.g. foo\\?

Gaming

Programming

Adding comment to object key