feat: add no-add-event-listener rule

[43081j]

this helped me learn about the events helpers, so figured i may as well throw it together.

let me know if there's anything i missed, as i don't think i've added a new rule in this repo before.

one thing to note is that it has a suggestion, but that relies on the user later making sure on has been imported correctly. im not sure we can do that automatically since each suggestion runs individually and should probably only affect the subset of code you're reporting

close: #1194

[changeset-bot]

🦋 Changeset detected

Latest commit: b19945f

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
eslint-plugin-svelte	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Try the Instant Preview in Online Playground

ESLint Online Playground

Install the Instant Preview to Your Local

npm i https://pkg.pr.new/eslint-plugin-svelte@2bc4c29

Published Instant Preview Packages:

• eslint-plugin-svelte: https://pkg.pr.new/eslint-plugin-svelte@2bc4c29

View Commit

[baseballyama]

I’d really appreciate it if we could help by adding some tests for now!
And please add changeset.

[baseballyama]

Do you think this should be shipped as a recommended rule? (It might cause a lot of errors in existing code, though.)
cc: @ota-meshi

[43081j]

ultimately i think it should be recommended, but im not sure how we can do that without introducing loads of errors like you say 🤔 it'd have to be in the next major i suppose

[baseballyama]

Let’s make it recommended in the next major release.

[baseballyama]

Should we also include the TypeScript case like this?

(window as any).addEventListener ('message', handler);
(window.addEventListener as any)('message', handler);

[43081j]

for this one, i added the test cases but this one isn't currently supported:

(window.addEventListener as any)('message', handler);

we would need logic to handle call expressions containing casts, which feels weird. maybe we should just ignore this case and not try handle it?

[baseballyama]

I’m not sure how complicated this is, so I’ll try implementing it myself later.

[43081j]

its not complicated, its just awkward that we'd need code which knows about casts

((window.addEventListener) as any) as any)('message', handler)

the callee is then a TSAsExpression

which means we'd need to traverse this node specifically stripping out/ignoring casts (because only casts create this situation)

i.e. you would do this flow:

const actualNode = findFirstNonCastNode(node);

// that actually does this
while (expression.type is TSAsExpression) {
  expression = expression.expression;
}

sure it'd make it work but it makes me feel like this for some reason: 😬

[baseballyama]

Please add changeset🙏

[baseballyama]

I’m not sure how complicated this is, so I’ll try implementing it myself later.