Feature request: Configuration option to disable generation of `[k: string]: unknown`

[binaryunary]

Hi,

Would you consider adding a config option to disable generation of [k: string]: unknown; if additionalProperties is not explicitly set to false?

I understand that technically the current behavior is correct as it follows the spec but [k: string]: unknown; allows referencing any arbitrary properties and makes it difficult to catch errors at compile time.

[tadhgmister]

you definitely want to complain to who ever owns the schema telling them to add additionalProperties: false since users of the schema that don't use typescript will face the same issue.

[bcherny]

Agreed with @tadhgmister -- while this may seem appealing, it's an easy way to introduce subtle bugs where codegenned typings behave differently for different languages. We want to stick as closely as possible to the JSON-Schema spec to make the compiler predictable and reliable.

Leaving this open for now to collect more feedback.

[johnbillion]

Agreed that this is a problem that should be fixed in the JSON schema, not at the point where its transformed into TS interfaces. If the JSON schema you're referencing is used for validation then the "any arbitrary properties" you refer to are perfectly valid.

[Karel-Kroeze]

while I agree that forcing additionalProperties to be false should never be the default, having the option to do so through an option for overly permissive schemas would be extremely handy.

[dhoepelman]

I would like to vote for this as a config option.
I'd even argue that it should be the default as typescript programs can always have excess properties¹.
So leaving it out doesn't change the meaning of the generated interface.

You don't always control the schema. additionalProperties: false can also lead to complications when evolving a schema.

You should still exclusively use known properties in your programs. [k: string]: unknown makes that harder to do.

Even assuming it's not correct to leave it out, a config setting is a minor problem for correctness at most while it saves complicated work-arounds².

¹ Typescript uses duck typing. It can only prevent additional properties in special cases.

Example (Playground Link)

const value = { a: 'a', b: 'b' }

function f(input: { a: string }) {
    console.log(Object.keys(input))
}
// no error but output is ["a", "b"] 
f(value)

² @nicojs already showed a work-around during generation

Since typescript 4.1 it's also possible to remove the [k: string]: unkown at the type level:

export type DefinedFields<T> = {
  [K in keyof T as string extends K ? never : K]: T[K];
};

[mgabeler-lee-6rs]

A reason to make this an option: TypeScript already treats all types as additionalProperties: true in many contexts, and you cannot suppress this AFAICT.

Fundamentally, TypeScript types and interfaces specify what a value must have, not what it must not have. Thus this is perfectly fine:

export interface Foo {
    bar: number;
    baz: string;
}
const x = {
    bar: 12,
    baz: "13",
    quux: [14],
};
const y: Foo = x;
const yy: Foo = { ...x };

const z = {
    bar: 12,
    baz: "13",
    quux: [14],
} as Foo;
const zz = { ...x } as Foo;

Playground Link

The only thing in this area where TypeScript would complain is this pattern:

const a: Foo = {
    bar: 12,
    baz: "13",
    quux: [14],
}
// Type '{ bar: number; baz: string; quux: number[]; }' is not assignable to type 'Foo'.
//   Object literal may only specify known properties, and 'quux' does not exist in type 'Foo'.

---

Second rationale: If you use allOf to combine schemas, you cannot set additionalProperties: false. If you do that, you generally end up with schemas which exclude all possible documents, because you e.g. have "schema X says must have props a and b and nothing else, schema Y says c and d and nothing else, so allOf[X,Y] must have a, b, c, and d, while also simultaneously having no properties at all". The response from the JSON schema folks to this problem seems to be, roughly, "we don't support inheritance".

This issue results in it being impossible for my team to have additionalProperties: false in almost any of our schemas.

[nbrahms]

👋 Hi folks,

I recently started testing out this tool to generate typescript types from a json-schema dependency in a project I'm working on.

I want to +1 this request and explain why we need it:

It's worth asking what the purpose of a jsonschema is. It can be used for multiple needs. In particular, it's most often used for data validation. In this case, additionalProperties: false tells the data validator that any unknown object property should result in a validation error.

In the case of json-schema-to-typescript, the jsonschema is more likely (and is, in my specific use case) used for code generation; viz., we want to make sure we don't write TypeScript code that accesses a missing field. Using json-schema-to-typescript's current behavior, we would have to set additionalProperties: false to prevent unbounded field access to objects.

Now let's consider creating a forward-compatible TypeScript consumer of an API, where the API is described by a jsonschema. In order to allow extension of the API in a forward-compatible manner, we should leave additionalProperties unset, to prevent schema validation errors. But in order to catch backward-incompatible changes in the schema in our TypeScript code, we need the generated type definitions to not include unbounded field accessors (i.e., [k: string]: unknown).

All the above is given one even has control over the jsonschema in question.

So TL;DR: I'd love to introduce json-schema-to-typescript to my team. This requested configuration option would make that a much easier sell 🙏 .