Feature proposal: add an option to control `additonalProperties` output

[toomuchdesign]

Currently JSON schema additonalProperties prop controls the addition of an index signature type:

// additonalProperties === true or not defined
type Result = {
  [x: string]: unknown;
  foo: string
}

// additonalProperties === false
type Result = {
  foo: string
}

..which is fine in most cases but sometimes it clashes with a few real use cases.

My real world scenario

I maintain a package of shared JSON schema used for both runtime validation and type check. Types are inferred with ❤️json-schema-to-ts❤️.

I tend to let my schemas accept foreign props (undefined additonalProperties) since they validate API input and output data, and I often need the validation to succeed when it finds new properties. This is the case when an api cascade is updated with new props and the deployment is sequential api1 -> api2 -> api3.

If all schemas defined closed object it would be technically impossible introducing new api props without breaking production.

If I prefer open (unsealed) objects when it comes to runtime validation (a single validation error could break production), I'd like to be stricter (even over-strict) when it comes to type check.

This is the reason why I'm considering the option of being able to infer my types handling additonalProperties differently. A few possible alternatives:

1. Ignore additonalProperties and never add the index signature type
2. Add the index signature type only when additonalProperties id explicitly set to true
3. Control additonalProperties output and decided what to add based on its value (true, false, undefined)

The problem is very evident at refactoring time when no-more existing properties are not detected by the type checker.

Of course all these scenarios should be enabled via a generic option which I know it's quite expensive to maintain and implement.

Conclusion

I'm aware this is an extremely complex and delicate library.

I'm just writing to gather feedback from other consumers and @ThomasAribart about the value and feasibility of such feature. As usual happy to provide my resources in case we decided to proceed.

Thank you so much for maintaining this gem.

[ThomasAribart]

Hi @toomuchdesign !

I think option 1 is fine as TS object types are never strict: An object assignable to { a: string } can have a property b.

However, I like keeping the { [x: string]: unknown; } to remind newcomers that object JSON-Schemas accept additional properties by default.

In any case, adding a omitAdditionalProperties option would not hurt :)

Note that TS-Algebra meta-objects already have a CloseOnResolve option so this shouldn't be too hard to implement.

[toomuchdesign]

Thank you for your quick reply! I agree the current default behaviour is correct.

I'll open a PR as soon as I have a good time to do it. Cheers!

[toomuchdesign]

Just an extra idea: would you be up for rewriting tests with jest (since the repo already uses it) + expect-type?

Type expectation would become shorter and probably more legible and each test case could be wrapped with proper describe/expectation blocks with proper tests description.

If you have preferences we could even consider switching to other testing runners.
Let me know if it's something you'd like to see happen. Greetings!