Unknown configuration options should throw an error

[simonjbeaumont]

Example, if you use featureFlag instead of featureFlags:

generate:
  - types
featureFlag:
  - nullableSchemas

This is easy to do because the CLI is --feature-flag (taking multiple).

We already print the following to stdout:

Swift OpenAPI Generator is running with the following configuration:
- OpenAPI document path: ...
- Configuration path: ...
- Generator modes: types, client
- Feature flags: ...
- Output file names: Types.swift, Client.swift
- Output directory: ...
- Diagnostics output path: <none - logs to stderr>
- Current directory: ...
- Plugin source: <none>
- Is dry run: false
- Additional imports: <none>

Probably should print something here about unknown keys?

[czechboy0]

We should probably fail on unknown keys, tbh. The danger of this issue is too real. We already fail if you provide an invalid feature flag, so I'd be supportive of going even more strict.

[simonjbeaumont]

Yeah, OK. I can see this biting with the additionalImports (cf. --additional-import) too.

[simonjbeaumont]

Is technically breaking an interface, so propose we pull into the 1.0 milestone.

[czechboy0]

Yeah. On the CLI, since you provide them one by one, the singular makes sense, but in the config file you provide them all at once, hence the plural. But typos are common and our diagnostics should be better here.

[czechboy0]

And I'd be for an error here, not even a warning. It's invalid input and the adopter should fix it ASAP, otherwise they might think they're enabling a feature or similar but they're not.

[czechboy0]

Is technically breaking an interface, so propose we pull into the 1.0 milestone.

True, changed.

[PARAIPAN9]

Hello again, I'd like to try this out if possible.

[czechboy0]

@PARAIPAN9, sure go ahead! 🙏