Given directory:
components|___foo | fooX | fooY | fooZ | index.ts|___bar | barA | barB | barC | index.ts
foo/index.ts
export * from './fooX';export * from './fooY';export * from './fooZ';
bar/index.ts
export * from './barA';export * from './barB';export * from './barC';
I'm assuming if you're here you already know what a barrel file is. But for those who don't, the index files referenced above are barrel files. It's a pretty easy way to be able to import/export modules without having to use specific paths for each. It also makes it easy to mass-import related modules; eg:
import { fooX, fooY, fooZ } from 'foo';
versus
import { fooX } from 'foo/fooX';import { fooY } from 'foo/fooY';import { fooZ } from 'foo/fooZ';
The problem:
Following this, you will probably definitely end up running into a warning about circular dependencies. Specifically:
Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
This is caused by the following cycle:
foo/index.ts -> fooX -> barB -> foo/index.ts
This is just one example. In practice, it could be a bigger cycle or an even smaller cycle, such as fooX referencing its parent's index to import, say, fooY. This will look something like this:
foo/index.ts -> fooX -> foo/index.ts
Looks pretty bad. Except, it's an innocent warning. In practice, you're not really creating a circular dependency. It looks that way, but it's not. This is because your index is calling fooX, but your fooX is only importing fooY from index. So really, it's foo/index.ts -> fooX -> fooY.
As a bigger example:
fooX.ts
import { barC } from '../bar';
barA.ts
import { fooY } from '../foo';
This will result in a circular dependency warning with the cycle being:
foo/index.ts -> fooX -> bar/index.ts -> barA -> foo/index.ts
As you can see in the imports, there's no real dependency there. But since the file in question is foo/index.ts, the engine automatically assumes you're in a circular dependency and throws the warning.
It's easy to ignore these warnings, since they have no effect. It's also easy to just add the warning to an ignore like LogBox.ignoreLogs so the console looks cleaner.
But my question is: aside from the following "solutions":
- adding them to an ignore list
- letting them clutter the console
- hardcoding a path (eg
import { fooX } from 'foo/fooX';
)
is there a way to treat these warnings?