Offer to set up ESLint in create-astro #621
JoshuaKGoldberg
started this conversation in
Proposal
Replies: 1 comment 1 reply
-
I think there was discussion to use |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Body
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.
.eslintrc.cjs
withenv
,extends
, andparserOptions
eslint-plugin-astro
:extends
andoverrides
extends
,parser
, andplugins
overrides
configuration foreslint-plugin-astro
@typescript-eslint/triple-slash-reference
rule fires onsrc/env.d.ts
, so you'll need to turn it off for that file or use an.eslintignore
...extends
andparserOptions
eslint-plugin-jsx-a11y
:extends
andplugins
eslint-plugin-react
andeslint-plugin-react-hooks
:extends
andplugins
eslint-plugin-solid
:extends
andplugins
You can see an example of an ESLint config for Astro with Solid here: https://github.com/JoshuaKGoldberg/joshuakgoldberg-dot-com/blob/7649e1fa12280ffdbf16c9887e8724de0b3203ab/.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, itssolid/prefer-for
rule will rewrite your Astro JSX loops to try to use Solid's<For>
. I learned that the hard way 😬 and it was very confusing+inconvenient at first.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
andeslint-plugin-astro
. An estimated >80% of survey-taking JS developers use ESLint. https://docs.astro.build/en/editor-setup/#eslint already points towardseslint-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
Example
How about in the Houston CLI experience, it also asks if we want an ESLint config?
...and if they're using a template with a view library, it should be included?
This would require installing dependencies later in the setup script.
Acknowledgements
Thanks to @ElianCodes for feedback on drafts of this RFC ❤️
Beta Was this translation helpful? Give feedback.
All reactions