`strict: true` should enable all strict mode options (aka, be like typescript)

[G-Rath]

What version of Ajv you are you using?
v7

What problem do you want to solve?
Whenever I enable strict mode I always pass strict: true, only to then remember that that doesn't do anything, as I've got to actually set two other properties to true.

What do you think is the correct solution to problem?
When I do strict: true, use that as the default for all strict-mode options - that way all strict-mode options will be enabled when I pass strict: true while allowing me to turn off the ones I don't want by explicitly setting them to false or log.

This is the behaviour I've come to expect from having worked with TypeScript for so long, as it's strict mode is pretty much the same as ajvs.

Will you be able to implement it?
Yes :)

[epoberezkin]

@G-Rath is the proposal to change strict: true to enable strictTypes and strictTuples, but keep strict: undefined to mean what it means now?

It probably needs to be better defined then and I think it may be better to postpone till v8 release in a couple of months...

Currently there is:

• strict - includes mostly preventing ignored keywords in schema and prevents ignored defaults and strictNumbers (that does feel an odd one)
• strictTypes - on top of strict: true
• strictTuples - on top of strict: true)

Possibly, with the change there would be:

• strictSchema (true by default) = strictKeywords (v6) + strictDefaults (v6) = strict (current) - strictNumbers (v6)
• strictNumbers (true by default) - as in v6
• strictTypes (log by default)
• strictTuples (log by default)
• strict: true - set all above to true
• strict: false - set all above to false

Does it make sense?

[G-Rath]

it may be better to postpone till v8 release in a couple of months

If a new major is coming out soon, then 💯 agree & am happy for it to wait until then since it'll give us more freedom.

Does it make sense?

Totally! I didn't realise strict by itself was enabling a few things.

Ultimately this boils down to "I want to have one property I can set to true or log to have it enable all (or most) strict-mode validations".

Then, thinking on how to go about that, it brings to mind the way TypeScript handle their strict mode and flags, which I think would be a good fit here too.

So yes the list of properties you've written up makes sense and I think would be good. The only adjustment I'll make would be on those last two:

• strict: true - set all above to true, unless explicitly provided
• strict: false - set all above to false, unless explicitly provided

This might have been what you were meaning, but want to be clear :)

Some examples

strictSchema (true by default) = strictKeywords (v6) + strictDefaults (v6) = strict (current) - strictNumbers (v6)
strictNumbers (true by default) - as in v6
strictTypes (log by default)
strictTuples (log by default)
strict: true - set all above to true
strict: false - set all above to false

{
  strictSchema: true,
  strictNumbers: true,
  strictTypes: true,
  strictTuples: true,
  strict: true,
}

{
  strict: true,
}
// is equivalent to
{
  strictSchema: true,
  strictNumbers: true,
  strictTypes: true,
  strictTuples: true
}

{
  strictTuples: true,
  strict: false,
}
// is equivalent to
{
  strictSchema: false,
  strictNumbers: false,
  strictTypes: false,
  strictTuples: true
}

{
  strictTypes: 'log',
  strict: true,
}
// is equivalent to
{
  strictSchema: true,
  strictNumbers: true,
  strictTypes: 'log',
  strictTuples: true
}

[epoberezkin]

Ok, yes - that’s what I meant - strictSomething overrides strict

atm strict: true indeed does not change anything - it’s just default. strictSchema and strictNumbers is just something that will be added to retain the current strict: true behaviour, no such options atm.

another options would be to allow strict as object with properties schema/defaults/types/tuples (in addition to true/false/log values) - maybe it’s better. in this case you either set strict or individual settings but not both, so it’s easier and less confusing.