-
Notifications
You must be signed in to change notification settings - Fork 53
Conversation
I need some more clarification! Why do you need to check if the file exists already?
What does Jetifier have to do with iOS? |
It has nothing to do with iOS but since I am doing this in a monorepo multiple RN apps are symlinked in my Xcode creates some lock-files for some reason and I can list them but when you run |
I assume the sub-optimality is performance? If that's right, I looked into it a little bit. You can see the timing statements in previous iterations of CI. This appears to be about 5-10% slower, but is still (in my opinion) within acceptable performance (it's sub-second for normal conditions, I think) and yes - it only executes on package install so it seems acceptable as a trade-off for correctness in monorepos In general I will always go for bulletproof correctness over performance, though it's nice to have both if possible. I would also avoid a blacklist, I'd prefer to keep it zero configuration if possible Maybe its possible to avoid some of the performance hit by treating what should be an exceptional case with exception handling vs checking every file. |
I don't think most of the users will face the same issue, so applying this to Jetifier will definitely impact performance! |
I could live with a command-line flag if @hampustagerud could - but I'm not too bothered by 5-10% performance in the default case either. I'd prefer to try handling it as an exception before adding a flag. I support a few libraries now and it's unbelievable how even the simplest configuration bits cause issues everywhere. The simpler the better with regard to usage 🙏 |
I agree that 5-10% is not a lot unless it was used for every build/reload. I don't think my project will be that special of a case now that RN 0.60 officially moved to androidx, maybe it will be but who knows? I can live with adding a flag but that would involve more documentation as well. Wrapping in try/catch performs similarly on my machine but I wanted to stay away from exception handling and just make sure that the file exists. By blindly traversing all files there will always be the possibility that some library builds some module that produces files that cannot be read for some reason. It is an edge case but it is something that breaks this code. I am not too versed in the androidx world, I am only here because I had to upgrade a library and some of the others were not compatible so I am not sure if this is a solution but I changed the check to stay out of build folders: if (filePath.indexOf('/build/') === -1) {
// Handle the file...
} This, naturally, improved performance instead since less files were found. I reduced my execution time with 50%. Would this be a better solution @m4tt72? 🙂 Like I said, I have not looked in to androidx that much so I don't know if what exists in the |
That's a good shot at improving performance but when I was originally building out the rn-androidx-demo test suite I use to check this I noticed that some libraries render java files (from something else? not sure what they were doing) and their java is in a build folder, so we can' blindly exclude on the build path Thanks for checking the try/catch performance, I had a hunch it would involve it's own performance hit @m4tt72 I know you are concerned with performance, as you are responsible for about 1000% of the speedups in this library :-), but for 5-10% (I checked, that's the real impact - I'm not guessing) and never having to worry, or document a thing, I'd like to just merge as is |
Humm, since you both agree on that, and this will definitely make the code more robust, then sure I'd rather have it working in all cases even if we sacrifice some of the performance... |
Thanks @m4tt72 - during the initial bits of transition as we hit all the edge cases I want more than anything to have this be at least one part of the rn60 experience that isn't frustrating. I'm actually going through it myself on my work app and it's basically a mess. But at least jetifier is working :-) and it will still be plenty fast with this I think, based on your previous work |
I tried to use this in a lerna monorepo but it failed due to some files not being found in a iOS build folder, checking if the file exists before running
statSync
on it solved the issue 🙂