Eslint-plugin-import: [import/no-cycle] possible false-positive with re-exported names

[silverwind]

Given these files:

a.js

import {b} from './internal';
export const a = 'a';

b.js

import {a} from './internal';
export const b = 'b';

internal.js

export * from './a';
export * from './b';

.eslintrc

plugins:
  - import

parserOptions:
  ecmaVersion: 2020
  sourceType: module

rules:
  import/no-cycle: [2]

I see these errors:

a.js
  1:1  error  Dependency cycle detected  import/no-cycle

b.js
  1:1  error  Dependency cycle detected  import/no-cycle

internal.js
  1:1  error  Dependency cycle detected  import/no-cycle
  2:1  error  Dependency cycle detected  import/no-cycle

This is a example of @mweststrate's internal module pattern and if I understand correctly, there are no actual circular dependencies here. Is it a false-positive or a error in the pattern itself?

[ljharb]

This is absolutely a circular dependency, because a requires internal, and internal requires a (and the same for b).

In other words, the pattern itself violates the no-cycle rule because it forces everything to be a cycle.

[silverwind]

I don't understand enough of how module resolution works, but I was under the impression that this pattern exploits a mechanism in the resolution that leads to modules being loaded in the order defined in internal.js, so the import in a will initially resolve to {}, then internal will load the modules and the re-exported values then resolve to the actual exports.

The pattern is in use in MobX so it apparently does work to some extent.

Some info from the linked post:

[ljharb]

Being a cycle is not about touching the filesystem; it's about conceptually creating a situation where two files mutually depend on each other.

What you're describing is how node's CommonJS makes circular dependencies possible - but they're still circular.

[silverwind]

I guess technically you're correct. I didn't really like that pattern anyways so I will avoid it.

[ljharb]