Should ScalarTag be generic?

[MindfulMinun]

Hi, I'm encountering some TypeScript problems when using this library. I have a document with a custom tag !day, and this is the ScalarTag I've come up with.

import { parseDocument, Scalar, ScalarTag, YAMLMap } from "https://esm.sh/yaml@v2.4.0"

const dayTag: ScalarTag = {
    tag: "!day",
    resolve: value => new Date(value),
    identify: value => value instanceof Date,
    stringify: scalar => scalar.value.toISOString().slice(0, 10)
}

Unfortunately, I get an error on the last line. According to TypeScript, I can't call toISOString on that value because it's unknown. I've also tried to change the function like so:

(scalar: Scalar<Date>) => scalar.value.toISOString().slice(0, 10)

but I get another error stating that unknown is unassignable to Date. Currently I'm using this code as a workaround:

scalar => (scalar as Scalar<Date>).value.toISOString().slice(0, 10)

but this leads me to think that ScalarTag should be generic and take an optional type parameter like so:

const dayTag: ScalarTag<Date> = {
    tag: "!day",
    resolve: value => new Date(value),
    identify: value => value instanceof Date,
    stringify: scalar => scalar.value.toISOString().slice(0, 10)
}

[eemeli]

It could be, but would that really be beneficial? At the moment, the typing is kinda forcing you to either:

1. Deal with the reality that a user could reassign a different value to your tag at runtime, or
2. Trust that this never happens, and use a typecast.

Both approaches are valid, but if the ScalarTag did let you narrow down the type, then you'd probably never consider the first choice. In the built-in tags (under src/schema/) you'll find both approaches being taken, with (in general) the "core" and "json" schemas doing runtime type checking, while the "yaml-1.1" schema makes more assumptions and typecasts.