Draft Astro RFC for ESLint in the setup experience

README.md

withastro/roadmap#621

Summary

ESLint is generally considered to be a useful, even necessary, tool for JavaScript/TypeScript web apps. However, configuring it can involve wrangling several configurations and plugins together. It would be useful for many Astro users if npm create astro et al. offered to set up a starting ESLint configuration.

Background & Motivation

Contained here are the most common setup points I think many Astro would need.

• [Required] "Stock"/"vanilla" ESLint: an .eslintrc.cjs with env, extends, and parserOptions
• [Required] eslint-plugin-astro: extends and overrides
• [Required for TypeScript] Adding typescript-eslint: extends, parser, and plugins
  • Note that this requires modifying the overrides configuration for eslint-plugin-astro
  • Note also that the @typescript-eslint/triple-slash-reference rule fires on src/env.d.ts, so you'll need to turn it off for that file or use an .eslintignore...
• [Optional, must be using TypeScript] Adding typescript-eslint type information: extends and parserOptions
• [Optional, but almost everyone should use it] eslint-plugin-jsx-a11y: extends and plugins
• [Optional] Adding framework-specific plugins, e.g.:
  • React: eslint-plugin-react and eslint-plugin-react-hooks: extends and plugins
  • Solid: eslint-plugin-solid: extends and plugins

You can see an example of an ESLint config for Astro with Solid here: https://github.com/JoshuaKGoldberg/joshuakgoldberg-dot-com-next/blob/15509d3c3177526fe0fb0fa4e2029903ac4a6874/.eslintrc.cjs.

Note that many of these plugins require using ESLint overrides in specific ways. For example, if you apply the Solid plugin to .astro files, its solid/prefer-for rule will rewrite your Astro JSX loops to try to use Solid's <For>.

That's a lot of configuration - and the vast majority of users aren't going to be able to get there. I'm a maintainer on typescript-eslint and it took me a few tries! 😄

Third Party Integrations

Each of the framework plugins -including Astro's- that would be installed are third-party plugins not maintained by Astro. This RFC's proposal effectively adds a dependency on those external plugins being trustworthy.

These plugins are already key parts of the Astro ecosystem: especially astro-eslint-parser and eslint-plugin-astro. An estimated >80% of survey-taking JS developers use ESLint. https://docs.astro.build/en/editor-setup/#eslint already points towards eslint-plugin-astro. We can assume users are already treating these plugins as a core part of the Astro experience. Directing more users to the plugins will help raise their visibility.

Goals

• Automate the process of setting up a "good" starter ESLint configuration for users based on their project needs
• Improve Astro app development flow & reliability by providing more comprehensive linting
• Increase community usage of specifically the Astro ESLint parser and plugin

Example

How about in the Houston CLI experience, it also asks if we want an ESLint config?

...

  deps   Install dependencies?
         Yes
      ✔  Dependencies installed

    ts   Do you plan to write TypeScript?
         Yes

   use   How strict should TypeScript be?
         Strict
      ✔  TypeScript customized

  lint   Would you like to add an ESLint configuration?
         Yes

config   What ESLint plugin(s) would you like to add?
         ● astro       (recommended)
         ● jsx-a11y    (recommended)
         ● typescript  (recommended)
         ○ alpinejs
         ○ lit
         ○ preact
         ○ react
         ○ react-hooks
         ○ solid-js
         ○ svelte
         ○ vue
...

...and if they're using a template with a view library, it should be included?

...
         ● typescript  (recommended)
         ● react       (recommended for your template)
         ● react-hooks (recommended for your template)     
         ○ alpinejs         
...

This would require installing dependencies later in the setup script.

Acknowledgements

Thanks to @ElianCodes for feedback on drafts of this RFC ❤️