call Rule.ruleEvent by its correct name

[emilefokkemanavara]

Currently, the types suggest that Rule has a property called event, but the property is actually called ruleEvent, as evidenced by this test. This PR fixes that by changing the type of Rule. This is not breaking because any TypeScript code referring to a Rule's event can never have worked.

[emilefokkemanavara]

@chris-pardy What do you think of this?

[chris-pardy]

@emilefokkemanavara getting to this finally. What I'd prefer to do is add a property to the rule called event and then we can make this a non-breaking change both on the types and on the implementation.

[emilefokkemanavara]

@chris-pardy But what I suggested above is already non-breaking, isn't it?

[emilefokkemanavara]

@chris-pardy I implemented your suggestion. Rule now has both.

[chris-pardy]

Looks good, I'll merge and deploy this later today.

[chris-pardy]

Last thing, we should mark one of these as deprecated.
No reason to remove it until a v8 but we should be starting that process.

[emilefokkemanavara]

So we'll deprecate ruleEvent, right? (Because we want a Rule to still implement RuleOptions RuleProperties)

[chris-pardy]

correct.

[chris-pardy]

@emilefokkemanavara to add a note here on the reason your original change would have still been a breaking change.

There's effectively 2 artifacts being distributed as part of this library - types and code. Because of the nature of Typescript there's no restriction on how the types are used.

For instance say I have something like:

type RuleThings = Partial<Record<keyof Rule, string>>;

const ruleThings: RuleThings = {
   'event': 'test'
}

When we dropped the event property it would have broken this code.

Making the change the way we did we
a) make any code that was trusting the typescript types work
b) keep any existing code that uses the ruleEvent property working