Require Cycle: lib/index.js -> lib/cycle.js -> lib/utils.js -> lib/index.js
This issue appeared after upgrading to [email protected] and [email protected]". Somewhere in react or react-native they recently added automatic tracking for require cycles.
So every time I run my application I now get a warning from react native, saying:
Require cycle: node_modules/jsan/lib/index -> node_modules/jsan/lib/cycle.js -> node_modules/jsan/lib/utils.js -> node_modules/jsan/lib/index.js
Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.
I'm using [email protected]
Getting the same issue here using react native 0.57.4. Seems to be coming from metro: metro issue 287
I'm open to a PR to fix this. There isn't any concern with the way the cycle is setup since module.exports is never being redefined so it safe to ignore. I'm not sure why the default config is to warn/lint for packages in node_modules
I'm not using React Native and don't have an emulator to check it, but I guess it's because of this part I introduced in #12: https://github.com/kolodny/jsan/blob/bba3737f2f36e67f9873eca03f19932817bd5080/lib/utils.js#L50-L53
restore from there is calling parse, while parse is calling restore (through decycle). Nothing bad in that, just that they are in different files/modules. Bringing them together in one file should make Metro happy, but we are losing in code usability. So the question is how crytical/annoying that warning is. I see there're no plans for https://github.com/facebook/metro/issues/287 so far.
The solution is to patch Metro as indicated in https://github.com/facebook/metro/issues/287#issuecomment-436504616.
Let's keep the issue open for now, so others can find.
I just updated a sample app dependencies and getting this error in code that seems out of my control. Seems like the temporary workaround is to put this in your root js file:
import { YellowBox } from "react-native";
YellowBox.ignoreWarnings(["Require cycle:"]);
This would require jsan to have react-native as a peerDep, something I'm not keen on. You could wrap this module in a module that makes that call and returns the jsan object. Shouldn't be too hard
Another solution is to change utils.js so that it requires './' inside restore function. Then the warning will not show up whenever jsan module is imported as it does now, but only when parsing object that had cycle references.