Rule proposal: the inverse of prefer-dom-node-dataset

[bschlenk]

Description

I work in a large codebase that happens to use lots of magic data attributes to change behavior of things in subtle ways. It can hurt greppability when seeing one of these data attributes used in css, but on the js side the data attribute is accessed via the dataset property. If you search the codebase for the data-* attribute you see in css, you won't find its usage on the js side and you have to know to strip the data and camelCase the name to find it.

It'd be nice if there was an inverse of prefer-dom-node-dataset, or if it took an option to invert the check.

Maybe this is easy enough to set up with no-restricted-syntax?

Fail

el.dataset.someLongDataAttribute

Pass

el.hasAttribute('data-some-long-data-attribute')

Proposed rule name

prefer-dom-node-has-attribute

Additional Info

For now I can use no-restricted-syntax with MemberExpression[property.name="dataset"], but an autofixer would be nice here.

[fregante]

I had the same experience with this rule: I disable it because it breaks greppability between JS and HTML

[silverwind]

A limited form of this exists at https://github.com/github/eslint-plugin-github/blob/main/docs/rules/no-dataset.md.

I would welcome a better version of that that handles replacement with getAttribute, setAttribute, deleteAttribute and possibly also hasAttribute. Last one might be ambigous and would need detection of boolean context so likely not autofixable.