Alt tag warning for image element is not correct

[tminhduc2811]

Hi, I'm using image props with an interface as below and eslint is showing a warning Image elements must have an alt prop, either with meaningful text, or an empty string for decorative images.

interface ImageProps {
  src: string
  width: number
  height: number
  alt: string
  priority?: boolean
}

const ImageList = ({ images, imgClassName }: { images: ImageProps[], imgClassName: string }) => {
  return (
    <Carousel responsive={CAROUSEL_RESPONSIVE} renderDotsOutside ssr>
      {images.map((image, index) => <Image key={index} className={imgClassName} {...image} />)}
    </Carousel>

  )
}

Correct me if I'm wrong but In this case, the alt tag is guaranteed by the interface and eslint shouldn't show the warning.

[JoshuaKGoldberg]

alt tag is guaranteed by the interface

This would require type information to understand reliably, which AFAIK in most userland code is generally only available with @typescript-eslint/eslint-plugin with TypeScript.

Has any thought been put towards making some of this repo's rules TypeScript-type-aware, or making a separate set of rules, or...?

[ljharb]

It's fine for rules to be type-aware, when available, as long as it's not the sole useful scenario for the rule.

[JoshuaKGoldberg]

A couple of implementation detail points that make being type-aware tricky:

• If the rule uses the typescript-eslint tooling to be type-aware, it'll be locked into TypeScript (i.e. Flow and any future competitors won't work for its type checking)
• In my (and other typescript-eslint maintainers') experience, it's generally confusing for users when rules provide different -even better!- results when the config changes to allow type checking

Those concerns might be small and not more important than getting better info. Either way, this scenario is something we probably need to make explicit docs for on typescript-eslint.io.

Out of curiosity @ljharb, have you seen other plugins add type-aware linting the way this issue is suggesting before?

[ljharb]

eslint-plugin-react and eslint-plugin-import have lots of examples to look at.

The one trick tho will be that we'll probably need to add the infrastructure for testing with the TS parser.

[myasonik]

There are quite a few rules that seem like the would be benefited from being type aware when that info is available.

Would contributing anything moving forward along these lines be accepted or does this project not want to get too involved with multiple parsers?

[ljharb]

@myasonik i'm totally fine with adding extra features when parsers provide extra information. The primary challenge is that we need to start running tests in the relevant parsers.

Once that's done, then we can start adding features that depend on them.

[ngtrio]

for anyone who runs into this, just add the code below to eslint.config.mjs

module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['jsx-a11y', '@typescript-eslint'],
  rules: {
    'jsx-a11y/alt-text': 'warn',
  },
};