vscode-eslint and eslint from command line following different formatting rules

[LinqLover]

I have set up eslint in my TypeScript project using the --init argument, created an .eslintrc.yml, and configured the VS Code extension with these settings:

{
	"editor.codeActionsOnSave": {
		"source.fixAll.eslint": true
	},
	"eslint.run": "onType"
}

Unfortunately, there is one file in my repository that is being judged differently by the CLI and the extension:

If I now reformat the file using the extension and then run $ eslint . --ext=.js,.ts,.json, I get 34 errors in the console each of them stating:

  22:1  error  Expected indentation of 4 spaces but found 8    indent
…
  34:1  error  Expected indentation of 8 spaces but found 12   indent

tl;dr, it looks as if vscode-eslint and eslint would follow a different set of rules. This is a problem for me because I want to use the CLI on CI whereas, in VS Code, I prefer the extension.

What could I have done wrong? Is there any other option I need to set in the settings.json? Or could this be a bug in the extension? Thanks in advance!

[LinqLover]

Update: I just defined a script in package.json as a shortcut for literally the command eslint . --ext=.js,.ts,.json from above, now it is following the same rules as the extension. Apparently eslint, when run directly in bash (pwd was the root of my repository), assumes a wrong context - I have no idea why. Should this be reported to the eslint team?

[rchl]

Is the eslint version the same in both cases?
Running from the command line might be using your global version that is different than the one in the project.

[LinqLover]

Surprisingly, it is not.

$ eslint --version
v6.8.0

versus

$ yarn lint-version
v7.26.0

So probably I should remove my global installation of eslint?

[rchl]

Having eslint installed per-project and using always that surely will give more predictable results. Especially with multiple people working on the same project.

[LinqLover]

Thank you, I just did this. Now I need to type npx eslint instead, but that's worth it, and also, I can define a node/yarn script to do this. :-)

(Also I found that for whatever reason, there was a package.json right in the ~ home directory of my machine ... 😳)