Thanks for filing this. This looks like a bug in ESLint itself, as our tooling doesn't have anything to do with the eslint config resolution process.

Could you please file this as a bug in the ESLint repo?
https://github.com/eslint/eslint

Thanks!

ok.
suspicious thing is that the only rules which misbehave so far are tslint rules (under @typescript-eslint/tslint/config). I've put only several rules in the bug demo, but our project of course uses many rules

hmm interesting, if it's only eslint-plugin-tslint rules, it might be a problem with our plugin.
I don't have a windows machine to look into this, would you be able to take a look?

I did some parallel debugging and so far I've found that in node_modules\@typescript-eslint\eslint-plugin-tslint\src\rules\config.ts a call const configuration = tslintConfig( receives tslintRules = { "encoding": true, "completed-docs": false } in either case, however, configuration.rules in buggy case is

{
  "encoding": {
    "ruleArguments": [],
    "ruleSeverity": "error"
  },
  "completed-docs": {
    "ruleArguments": [],
    "ruleSeverity": "error"
  }
}

while in normal case it's

{
  "encoding": {
    "ruleArguments": [],
    "ruleSeverity": "error"
  },
  "completed-docs": {
    "ruleArguments": [],
    "ruleSeverity": "off"
  }
}

So it seems the call const tslintConfig = memoize( incorrectly uses only the rule keys for a memoization cache key ${lintFile}_${Object.keys(tslintRules).join(',')}...

UP: yes, that should be it, checked on my case using JSON.stringify instead.

Probably, the result is different on Windows just because of different traversing order

I'd be happy to accept a PR if you've got a fix for it.