Exact record support

[reinismu]

Added .exact() for Record. It allows to check that incoming object doesn't have additional fields.

Close #41

First I tried to create { strict: true }, but validate, check etc. are shared between multiple Runtypes and they don't really need that setting.

[coveralls]

Coverage increased (+0.02%) to 99.12% when pulling b3587a2 on reinismu:master into 69b8724 on pelotom:master.

[jraoult]

@reinismu I'm excited about this. Have you heard from @pelotom regarding this PR?

[reinismu]

Nop :/

I made my own build so I could use this change + Omit

"dependencies": {
    "runtypes": "github:reinismu/runtypes#with-pick-omit"
  },

If you are interested

[jraoult]

@reinismu cheers, I ended up moving to zod anyway. It wasn't too hard after all. I feel this project is sadly losing momentum and zod provide strict check by default out of the box and some other nice goodies API wise.

[bayareacoder]

@reinismu You closed this issue but does it work for an object with both required and optional keys, to make sure there are either no required keys missing, or no additional keys, beyond the optional ones, specified? I don't see that case in your tests.
I believe this is a very common use case to eg test an API response.
We use this library and found a way to check for this that works, but is not elegant:

const allowedKeys = ['requiredKey1', ..., 'requiredKeyM', 'optionalKey1', ..., 'optionalKeyN'];
const RTtype = Record({
requiredKey1: ...
...
requiredKeyM: ...
})
.And(Partial({
optionalKey1: ...
...
optionalKeyN: ...
})
.And(Dictionary(Unknown, allowedKeys));

This will check that:

• all required keys are present and of correct type
• optional keys, if present, are of the correct type
• no additional keys are present.

Basically I don't think an exact spec on any intersection type works, since it's not the same as the intersection of the exact types...

[reinismu]

@jraoult Thanks! It seems promising

@bayareacoder From use of it I have noticed few edge cases where it doesn't work. One of them is when trying to use Or

[yuhr]

This would come in handy once #113 get merged, as there will be no need to use a tricky syntax like Record({ x: Number }).And(Partial({ y: Number })) in order to define partially-optional records. We will be able to write it as Record({ x: Number, y: Optional(Number) }), so it's compatible with the .exact() API.