Is the TypeScript type definition wrong?

As follow-up of a discussion started in #986, is the TypeScript definition wrong?

The definition is quite huge, ~1200 lines. The main reason for this is because it prevents TS users to do things like test.serial.serial or test.before.after, etc. But as noted by @thejameskyle, this isn’t really representing the runtime structure of AVA.

Also test.serial.serial is not an invalid combination. option-chain is designed so that the latter properties in the chain take precedence.

So although it looks weird and nobody should do it, it’s perfectly possible and maybe shouldn’t be restricted by the type definition?

These things should/can be prevented by the AVA ESLint rule. This means off course, we should create a AVA TSLint rule as well.

Just wanted to start the discussion over here. Everybody that has useful insights, feedback or whatever, feel free to chime in.

// @ivogabe @sindresorhus @novemberborn @jamestalmage

[jamiebuilds]

I think I’ll respond to all of that by saying please don’t add complexity for complexity’s sake when there is no noticeable positive impact to anyone.

Enforcing this means:

Cons:

• Writing generation scripts for types for both Flow and TypeScript
  • Making contribution harder
    • Making it far more likely to fall out of date
• Writing an option to the option-chain library that adds a bunch of complexity
  • You’ll have to deal with conflict resolution
  • And you still haven’t dealt with broad => specific option groups, which is an api nightmare

Pros:

• People won’t be able to do the thing they are already not doing and doesn’t cause any issues either way

[ivogabe]

@rcorrear context for beforeEach/afterEach was fixed in #1008. I’ve got a fix for always in #1025.