Align with Standard's React and JSX configs

[nickmccurdy]

There are newer configs and rules in eslint-config-standard-react and eslint-config-standard-jsx that I'd recommend looking into, especially for supporting the new JSX runtime.

Alternatively, it may be easier to extend from the following configs directly:

• https://github.com/standard/eslint-config-standard
• https://github.com/standard/eslint-config-standard-react
• https://github.com/standard/eslint-config-standard-jsx
• https://github.com/prettier/eslint-config-prettier

[npetruzzelli]

Hi @nickmccurdy , thanks for the suggestion. I apologize for taking so long to respond.

The purpose of this config is to take the guess work out of getting Prettier and JavaScript Standard Style (JSS) to work together. "What plugin should I use?" "What configs should I extend, and is what order?"

Getting this done used to be more complicated, but it became a bit easier when the plugin for JSS was deprecated and we now only need to be concerned with the config. You also used to account for multiple end points in eslint-config-prettier before it was combined into a single file.

It is intended to work as a base for any JavaScript project, regardless of whether it is Deno, Node.js, or Browser based. It is not concerned with other concerns, such as specific libraries and frameworks.

What I've done can be done much more simply by someone who is used to creating ESLint configurations:

// .eslintrc.js
module.exports = {
  plugins: ['prettier'],
  extends: ['standard', 'prettier'],
  rules: {
    'prettier/prettier': 'error'
  }
}

// `prettier.config.js` or `.prettierrc.js`
module.exports = 'prettier-config-standard'

...but I jumped through a number of hoops to make partial configurations possible. This should allow you to bring in project specific concerns, such as React. Project specific concerns are not the objective of this config.

The important part is that eslint-config-prettier is extended last to disable potential conflicts. You still have manage non-core conflicts on your own.

I admit that in most new projects (work related or personal) one of the first things I do is take a config like this, and add on many more plugins and rules related to TypeScript, React/Node, and Babel. I've done it enough that I may just make another config for it, but eslint-config-prettier-standard will always remain its own thing because it has the goal of making it an easy place to start, even if all you care about is core JavaScript or core Node.js

[npetruzzelli]

A react project might look like:

// .eslintrc.js
module.exports = {
  plugins: ['prettier'],
  extends: ['standard', 'standard-jsx', 'standard-react', 'prettier'],
  rules: {
    'prettier/prettier': 'error'
  }
}

// `prettier.config.js` or `.prettierrc.js`
module.exports = 'prettier-config-standard'

I still need to look closely at JSX and REACT configs to see if they overlap.

eslint-config-prettier-standard intentionally avoids being associated with a specific framework or library. I would need a separate repo along the lines of eslint-config-prettier-standard-react. Maybe a small monorepo since they are reasonably related.

Maybe an alternate entry point could be offered with @rushstack/eslint-patch/modern-module-resolution built in (see https://github.com/eslint/eslint/issues/3458)

[npetruzzelli]

@nickmccurdy - did you have a specific objective in mind when you opened this issue? I don't see React specific rules being added to this config, but the knowledge sharing was appreciated.

[nickmccurdy]

Thanks for the explanations. From what I recall I was looking for a complete solution with all the ESLint and Prettier configs I'd need for React, and noticed this config included some of the base Standard configs but not the configs for React. I'm no longer using Standard because of its accessibility issues (see Rationale for prettier-config-a11y) and eslint-config-prettier is now the recommended way to configure ESLint with Prettier, so I'd probably set up new projects manually with different configs.

That being said, I think other users could get confused if they also come across this package expecting integration with tools like React. As a result, I'd recommend adding some docs about setting up supplemental configs if you plan on maintaining this, and deprecating the package in favor of individual configs if you don't.