You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Metro bundler does not handle require cycles well. While webpack could fix/ignore these cycles as a crutch, Metro chooses to have you deal with them, which I like.
Require cycles can affect app performance, slowing down some components and add unnecessary depth to items (even with webpack). These cycles should be resolved and in some cases can cause larger issues of things being undefined. If we're lucky, the ones that are impacting the repo are showing up as red and yellow screens without broken components.
By resolving these we can improve the stability of the app while making it more performant.
How do I identify them?
Metro is pretty good about letting us know if these are here, although I have witnessed a case where they have been so deep in the require stack that it took commenting code out to get to the level where they'd show up.
Possible symptoms of these require cycles:
breakage in features directly related to the require cycle
longer load times of a component
How do I fix them?
A pattern that we make use of in this codebase is exporting something from file A and then importing/exporting it via a central index file. That index is then consumed elsewhere throughout the app and unfortunately causes cycles.
A lot of this will probably boil down to:
changing imports to not be that central index import (and updating the imports to directly import from the exported location)
looking for anything that imports from '.'
looking for where FileA imports FileB and FileB imports FileA and moving one of these exports into a separate file
Invocation
npm i -g dpdm
dpdm index.js
--warning false to disable warnings (not recommended since it may be a file you need to look into)
--tree false to ignore the large tree representation that is printed out
Both flags are enabled by default and are useful for debugging if files are included or if there is an issue with how things are being imported. If you see an ignored file in the warning section, you can modify the include or exclude paths.
Going further
This may not be enough to find and fix all of our cycles. It may be necessary to take our own packages we maintain out of node_modules and analyze them independently from within their own entry point (and not AAO-React-Native's entry point).
cp -r node_modules/@frogpond/some-dep ./some-dep
cd some-dep
dpdm dist/index.js
The text was updated successfully, but these errors were encountered:
The project has:
We can find these with the dpdm package.
📝 Full output
Why we need to remove these
Metro bundler does not handle require cycles well. While webpack could fix/ignore these cycles as a crutch, Metro chooses to have you deal with them, which I like.
Require cycles can affect app performance, slowing down some components and add unnecessary depth to items (even with webpack). These cycles should be resolved and in some cases can cause larger issues of things being undefined. If we're lucky, the ones that are impacting the repo are showing up as red and yellow screens without broken components.
By resolving these we can improve the stability of the app while making it more performant.
How do I identify them?
Metro is pretty good about letting us know if these are here, although I have witnessed a case where they have been so deep in the require stack that it took commenting code out to get to the level where they'd show up.
Possible symptoms of these require cycles:
How do I fix them?
A pattern that we make use of in this codebase is exporting something from file A and then importing/exporting it via a central index file. That index is then consumed elsewhere throughout the app and unfortunately causes cycles.
A lot of this will probably boil down to:
Invocation
npm i -g dpdm
dpdm index.js
--warning false
to disable warnings (not recommended since it may be a file you need to look into)--tree false
to ignore the large tree representation that is printed outBoth flags are enabled by default and are useful for debugging if files are included or if there is an issue with how things are being imported. If you see an ignored file in the warning section, you can modify the include or exclude paths.
Going further
This may not be enough to find and fix all of our cycles. It may be necessary to take our own packages we maintain out of node_modules and analyze them independently from within their own entry point (and not AAO-React-Native's entry point).
cp -r node_modules/@frogpond/some-dep ./some-dep cd some-dep dpdm dist/index.js
The text was updated successfully, but these errors were encountered: