adding .eslintrc.js configuration file disables webpack eslint-loader

[Kevin-Hamilton]

Description

After having worked with gatsby for a couple months, I tried customizing my EsLint to better align with coding conventions used at my company. After following these instructions, I was surprised to find that gatsby develop stopped showing eslint warnings altogether, and without any info messages nor further documentation on the eslint config page letting me know what might be expected of me to bring eslint warnings back to my development builds.

In researching this, I found the issue #8840 which explains that this is by design, and pointing to gatsby-plugin-eslint. gatsby-plugin-eslint seems fine for more complex usages of eslint, but seems like more work than necessary for simple one or two rule adjustments, compared to simply adding a .eslintrc.js to the project with:

module.exports = {
  rules: {
    // require use of semicolons instead of ASI
    semi: ["warn", "always"],
  },
};

I tried changing my local gatsby to allow webpack eslint-loader to use my project eslint config, and it seems to work fine. I am not a webpack, eslint, or gatsby expert, though, so I don't know what the unintended side effect of making this change would be.

diff --git a/packages/gatsby/src/utils/eslint-config.js b/packages/gatsby/src/utils/eslint-config.js
index f48e16b..38c4d9b 100755
--- a/packages/gatsby/src/utils/eslint-config.js
+++ b/packages/gatsby/src/utils/eslint-config.js
@@ -2,7 +2,7 @@ import { printSchema } from "graphql"
 
 module.exports = schema => {
   return {
-    useEslintrc: false,
+    useEslintrc: true,
     baseConfig: {
       globals: {
         graphql: true,
diff --git a/packages/gatsby/src/utils/webpack.config.js b/packages/gatsby/src/utils/webpack.config.js
index d49f0a9..1dea65d 100755
--- a/packages/gatsby/src/utils/webpack.config.js
+++ b/packages/gatsby/src/utils/webpack.config.js
@@ -14,7 +14,6 @@ const { withBasePath, withTrailingSlash } = require(`./path`)
 
 const apiRunnerNode = require(`./api-runner-node`)
 const createUtils = require(`./webpack-utils`)
-const hasLocalEslint = require(`./local-eslint-config-finder`)
 
 // Four stages or modes:
 //   1) develop: for `gatsby develop` command, hot reload and CSS injection into page
@@ -262,10 +261,7 @@ module.exports = async (program, directory, suppliedStage) => {
         // get schema to pass to eslint config and program for directory
         const { schema, program } = store.getState()
 
-        // if no local eslint config, then add gatsby config
-        if (!hasLocalEslint(program.directory)) {
-          configRules = configRules.concat([rules.eslint(schema)])
-        }
+        configRules = configRules.concat([rules.eslint(schema)])
 
         configRules = configRules.concat([
           {

If there are good reasons not to make the above change, then I would recommend that the ESLint documentation be updated to explain gatsby-plugin-eslint usage, and the gatsby develop command should be updated to notify/warn if it detects a local eslint file and let you know it is disabling webpack eslint-loader and then maybe point to the ESLint documentation.

Steps to reproduce

Add .eslintrc.js file to the root of the project. Run gatsby develop.

Expected result

ESLint rules should merge with the gatsby baseConfig. Or else a message could be displayed informing that eslint is now disabled and link to gatsby-plugin-eslint as the next steps to re-enabling it.

Actual result

ESLint no longer occurs when running gatsby develop

Environment

Run gatsby info --clipboard in your project directory and paste the output here.

System:
OS: macOS 10.14.4
CPU: (8) x64 Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 10.15.3 - ~/.nvm/versions/node/v10.15.3/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 6.9.0 - ~/.nvm/versions/node/v10.15.3/bin/npm
Languages:
Python: 2.7.10 - /usr/bin/python
Browsers:
Chrome: 74.0.3729.131
Firefox: 66.0.3
Safari: 12.1
npmPackages:
gatsby: ^2.3.24 => 2.4.2
gatsby-image: ^2.0.39 => 2.0.41
gatsby-plugin-lodash: ^3.0.5 => 3.0.5
gatsby-plugin-netlify: ^2.0.13 => 2.0.16
gatsby-plugin-polyfill-io: ^1.1.0 => 1.1.0
gatsby-plugin-react-helmet: ^3.0.12 => 3.0.12
gatsby-plugin-react-svg: git+https://github.com/jacobmischka/gatsby-plugin-react-svg.git => 2.1.1
gatsby-plugin-remote-images: ^1.0.1 => 1.0.1
gatsby-plugin-sass: ^2.0.11 => 2.0.11
gatsby-plugin-sharp: ^2.0.35 => 2.0.36
gatsby-plugin-styled-components: ^3.0.7 => 3.0.7
gatsby-remark-images: ^3.0.11 => 3.0.11
gatsby-source-filesystem: ^2.0.29 => 2.0.33
gatsby-source-wordpress: ^3.0.54 => 3.0.58
gatsby-transformer-hjson: ^2.1.8 => 2.1.8
gatsby-transformer-json: ^2.1.11 => 2.1.11
gatsby-transformer-remark: ^2.3.8 => 2.3.12
gatsby-transformer-sharp: ^2.1.18 => 2.1.19
npmGlobalPackages:
gatsby-cli: 2.5.12

[gatsbot]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contributefor more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[Kevin-Hamilton]

This is not stale.

Friendly ping to the gatsby team - could someone comment on this, or add a not stale label, please?

[KyleAMathews]

Yeah... I'm not sure why we don't just use your .eslintrc file. /cc @pieh @gatsbyjs/core thoughts?

[wardpeet]

Seems like a good idea to enable this as long as we merge our own config.

[n8tb1t]

I'm having the same issue.
ESLint rules should merge with the gatsby baseConfig.

[wardpeet]

We're open for pull requests 😄

[Kevin-Hamilton]

@wardpeet if the diff in my post above looks good to you, I could submit that as a pull request...?

[wardpeet]

Looks like it. Put one up :) we'll iterate from there.

[scnroy]

I can open a separate issue, but I wonder if this is why client sourcemaps aren't working for me. Example repo: https://github.com/scnroy/gatsby-eslint-loader

Expected result

Correct line number and highlighted snippet.

Actual result

[a7993n]

Same prob here

[LekoArts]

This since then has been addressed with https://www.gatsbyjs.com/docs/reference/release-notes/v3.0#eslint-7 when we did the migration