46

I am reconfiguring my project from tslint to eslint. I can run eslint manually, but webpack fails to run with this error message: 

Module build failed (from /path/node_modules/eslint-loader/index.js):
Error: Failed to load plugin @typescript-eslint: Cannot find module 'eslint-plugin-@typescript-eslint'

I have ruled out bad .eslintrc.js and missing dependencies since it works when I run it manually ./node_modules/eslint/bin/eslint.js ./ --ext .ts,.tsx --config ./.eslintrc.js

I'm not sure if this is an upstream issue with eslint-loader. 

module.exports = {
  parser: "@typescript-eslint/parser",
  plugins: ["@typescript-eslint"],
  extends: ["eslint:recommended", "plugin:@typescript-eslint/recommended", "plugin:react/recommended", "plugin:jest/recommended", "prettier", "prettier/@typescript-eslint"],
  rules: {
    "react/prop-types": false
  },
  parserOptions: {
    ecmaVersion: 6,
    project: "./tsconfig.json",
    sourceType: "module"
  },
  settings: {
    react: {
      version: "detect"
    },
    linkComponents: [
      {"name": "Link", "linkAttribute": "href"}
    ]
  },
  env: {
    browser: true
  }
};

My package.json

{
    "dependencies": {
        "@emotion/core": "10.0.6",
        "facepaint": "1.2.1",
        "react": "16.7.0",
        "react-dom": "16.7.0",
        "react-redux": "6.0.0",
        "redux": "4.0.1",
        "tslib": "1.9.3"
    },
    "devDependencies": {
        "@types/node": "10.12.21",
        "@types/react": "16.8.1",
        "@types/react-dom": "16.0.11",
        "@types/react-redux": "7.0.1",
        "@typescript-eslint/eslint-plugin": "1.2.0",
        "eslint": "5.13.0",
        "eslint-config-prettier": "4.0.0",
        "eslint-plugin-jest": "22.2.2",
        "eslint-plugin-react": "7.12.4",
        "tsconfig-paths-webpack-plugin": "3.2.0",
        "typescript": "3.2.1"
    }
}
Thilak Rao
  • 1,841
  • 2
  • 19
  • 26

2 Answers2

12

You need to upgrade your eslint version, in the error you can see a bad prefix eslint-plugin- due to some const in eslint/lib/config/plugins.js which was removed in later versions.

krulik
  • 976
  • 1
  • 10
  • 31
  • I use `eslint-loader`. Just figured out that it uses an older version of eslint, unless you specify the path to eslint using config options. I was able to fix it, but ran into other issues. Looks like eslint-loader does not support the newest version of eslint. – Thilak Rao Apr 28 '19 at 11:34
  • @ThilakRao did you try to update the eslint-loader correspondently? – krulik Apr 29 '19 at 13:40
  • @krulik Yeah, I'm on the latest version of `eslint-loader` (v2.1.2), but did not fix my issue. – Thilak Rao Apr 29 '19 at 17:41
  • I'm on "eslint": "^6.1.0", and "eslint-loader": "^2.0.0", and still same error – Damian Green Aug 17 '19 at 19:59
  • for upgrading Eslint I just run npm i -G eslint – Oleksandr Hrin Mar 19 '22 at 15:41
-79

I fixed this error by replacing all the ^ to empty in the package.json, and then npm i.

enter image description here

Jeff Tian
  • 5,210
  • 3
  • 51
  • 71
  • 14
    This is a very wrong proposal. It may cause your project breaks. – Jakub Hrubý Nov 05 '20 at 11:02
  • 3
    Why? It just fixed all the package's versions and it's very common for serious development, because it's more safe to do so. – Jeff Tian Nov 17 '20 at 01:36
  • The reason this is wrong is because `^` is a symbol used in semVer versioning that marks how specific the version should be. Simply removing this symbol may have fixed the issue for you (because it caused npm to install a different version of eslint) in this case but it will likely have many more unexpected implications. For this reason it's really discouraged and dangerous. – Brady Dowling Aug 19 '21 at 14:33
  • 3
    @BradyDowling Not actually true. Removing ~ or ^ is specifying which version it should use. It will never update a dep without your explicit instruction. ~ means it will only update the Build, but not the minor version. ^ means that it will update the minor and build but not the major. In this regard, you can control when you update to a newer version. So this isn't wrong in the technical sense. – c0dezer019 Oct 22 '21 at 16:06
  • 3
    @JeffTian You're wrong in that you did this to every single package. You performed a blanket operation to fix a problem related to only once package and you probably didn't know which one was causing the issue. Blanket removing SemVer can break your project because you may have features that rely on features of a package that aren't available in the minor version specified. You should only remove SemVer for packages you know need to stay fixed. – c0dezer019 Oct 22 '21 at 16:13