feat: 🎸 improve yar values and flash typings

[damusix]

• This is a proposition to enforce yar typings
• Increases visibility into session data
• Enforces consistent flash types

[Marsup]

My suggestions seem to fix the export error while still passing the tests. I think we should include error tests to make sure types are just what they pretend to be

[damusix]

ready now

[kanongil]

While it makes sense to more strictly type the entries, this approach seems too simple/broken.

Eg. the new generics are pointless since any override must extend from YarValues/YarFlashes. It's not possible to do request.yar.get<{ a: string }>('a') if other custom properties have been added to YarValues.

I'm also missing tests around how set(object) handles errors. Does it even error, or will it accept any object? There are multiple interesting cases here. Also, it would be nice if expect.type() was used to validate the returned types.

[damusix]

While it makes sense to more strictly type the entries, this approach seems too simple/broken.

Eg. the new generics are pointless since any override must extend from YarValues/YarFlashes. It's not possible to do request.yar.get<{ a: string }>('a') if other custom properties have been added to YarValues.

I'm also missing tests around how set(object) handles errors. Does it even error, or will it accept any object? There are multiple interesting cases here. Also, it would be nice if expect.type() was used to validate the returned types.

Thank you for the feedback it was very insightful. You actually unblocked my though process given what you alluded to about get<{ a: string }>('a'). Looking deeper into it, I even overlooked some issues that don't reflect the reality of how the library works. Currently working on an improvement with better types and tests as you suggested. Check back next week!

[damusix]

@kanongil

• Can set typed or untyped keys: https://github.com/hapijs/yar/pull/169/files#diff-cfc7807f6b174e1c3705c5c2747f56e49a889a52999dc96e4080a3af0131a534R121
• Can set typed or untyped object: https://github.com/hapijs/yar/pull/169/files#diff-cfc7807f6b174e1c3705c5c2747f56e49a889a52999dc96e4080a3af0131a534R128
• Can get types or untyped keys: https://github.com/hapijs/yar/pull/169/files#diff-cfc7807f6b174e1c3705c5c2747f56e49a889a52999dc96e4080a3af0131a534R134
• Can flash typed or untyped values: https://github.com/hapijs/yar/pull/169/files#diff-cfc7807f6b174e1c3705c5c2747f56e49a889a52999dc96e4080a3af0131a534R156
• All return types should reflect reality

[Marsup]

The PR looks all right, why did you need all those declarations with unknown though?

[damusix]

@Marsup this allowed the autocomplete to pick up <T extends YarValKeys>(key: T, value: YarValues[T]) as well as (key: string, value: T), allowing for typed yar values, and also unknown values. Without the <T = unknown>, it wouldn't pick up any types and set values to any. This was the "AHAH!" moment from @kanongil 's comment.

[Marsup]

OK, I tend to avoid overloads whenever possible as it makes manipulating types much harder, if there's no other way 🤷🏻‍♂️

[Marsup]

@kanongil does it address your concerns properly?

[damusix]

@kanongil Mind lending a follow up? This would be cool to be able to use.