`no-cycle` does not raise error on circular dependency?

There are three files:

src/a.ts:

import y from "./b";

const x: number = y + 1;
export default x;

src/b.ts:

import x from "./a";

const y: number = x + 1;
export default y;

src/c.ts:

import x from "./a";
import y from "./b";

console.log(x, y);

and the configuration is:

{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:import/errors",
    "plugin:import/warnings",
    "plugin:import/typescript"
  ],
  "plugins": [
    "@typescript-eslint",
    "import"
  ],
  "parser": "@typescript-eslint/parser",
  "settings": {
    "import/parsers": {
      "@typescript-eslint/parser": [
        ".ts",
        ".tsx"
      ]
    }
  },
  "rules": {
    "import/no-cycle": [
      "error",
      {
        "maxDepth": 10,
        "ignoreExternal": true
      }
    ]
  }
}

Given the command

$ yarn eslint src\c.ts
yarn run v1.22.10
$ D:\Projects\graphact\server\node_modules\.bin\eslint src\c.ts
Done in 2.03s.

no error occurs while c.ts imports both a.ts and b.ts, which are circular importing each other!

Is it the desired behavior, or I missed something?

[Yaojian]

Still not working after adding import/extensions.

I setup a test project on https://github.com/Yaojian/no-cycle-test

[Slapbox]

Check out #2103.

The next step here, I think, is to install eslint-plugin-import via setting a specific commit ID in the package.json and to test if we can find a commit where either of these bugs were not present. There’s not many commits, so most of the work involved here (should) be just starting/stopping costs of taking on a next task and waiting for npm installs.