In #457, we added a concept of stale pods flag, that was used to mark whether pod install command should run as a consequence of node_modules.
Since that time, I got bitten by this setting causing unexpected rebuilds to the point where some projects I'm testing run native build every single time despite no change in fingerprint.
In general I don't like the fact we are adding additional state to facilitate checks that seemingly can be done offline. From my testing, I'm now a bit confused as to what was the purpose of this flag as #457 lacks a proper description and we also don't have any inline comments about this flag and related code. Therefore I'm assuming that the purpose of it was that we trigger pod installation if we had to reinstall node_modules. However, this still seem to not be necessary, as fingerprint seems to deal with this type of scenarios well. Specifically, when we add new native dependencies that get installed in node installation phase, fingerprint will detect that and trigger native rebuild.
On top of that, this mechanism, regardless of whether I guessed the original reason for it, is there to prevent from stale builds being used. However, it still appears like it is much easier for the users to recover from issues that may arise from stale native builds than to recover from persistent rebuilds taking many minutes. In the former scenario, all you need to do is to trigger "clean build" reload. In the latter, there's no way for the user to debug that, and I experienced that myself.
Fixes # (issue)
Test expo-router app, add native dependency, test again
I also tested this on reanimated repo example apps with yarn and that's where I've been experiencing the described issue of consistent rebuilds.
In #457, we added a concept of stale pods flag, that was used to mark whether pod install command should run as a consequence of node_modules.
Since that time, I got bitten by this setting causing unexpected rebuilds to the point where some projects I'm testing run native build every single time despite no change in fingerprint.
In general I don't like the fact we are adding additional state to facilitate checks that seemingly can be done offline. From my testing, I'm now a bit confused as to what was the purpose of this flag as #457 lacks a proper description and we also don't have any inline comments about this flag and related code. Therefore I'm assuming that the purpose of it was that we trigger pod installation if we had to reinstall node_modules. However, this still seem to not be necessary, as fingerprint seems to deal with this type of scenarios well. Specifically, when we add new native dependencies that get installed in node installation phase, fingerprint will detect that and trigger native rebuild.
On top of that, this mechanism, regardless of whether I guessed the original reason for it, is there to prevent from stale builds being used. However, it still appears like it is much easier for the users to recover from issues that may arise from stale native builds than to recover from persistent rebuilds taking many minutes. In the former scenario, all you need to do is to trigger "clean build" reload. In the latter, there's no way for the user to debug that, and I experienced that myself.
Fixes # (issue)