Build step to generate initial modules
matt-dalton opened this issue · comments
Is your feature request related to a problem? Please describe.
I love the library, and think every RN app should make use of it. However one practical constraint is how to populate the packager modules here: https://kirillzyusko.github.io/react-native-bundle-splitter/docs/metro
Perhaps there are solutions to this, but it's not clear how my team should approach keeping these up-to-date. Do we need to remember to update these each time we touch certain files/dependencies? How realistic is this?
It's also not totally clear to me if there are significant performant consequences for forgetting to add a few modules.
Describe the solution you'd like
It would be amazing if we could generate this file based on a build step. It's possible something like this already exists. But incorporating this into this library would make it a complete solution.
If you do have any external tool recommendations - that would also be greatly appreaciated!
Describe alternatives you've considered
Tried looking for ways to do this, but haven't found anything so far
Additional context
Hi @matt-dalton
Thanks for interesting and detailed question!
Unfortunately right now there is only one way, how to grab this info - manually from console output. We are using react-native-debugger and there is possibility to copy output of investigate via one button Copy.
On our project we simply added template for PRs. In this PR we have checklist, and one of step is updating packager content. I know, it's not an ideal way. But there is a relative advantage here: since the developers do this every time, they control what exactly was updated in the folder. And if many new dependencies were added, then obviously something is wrong with the code.
Regarding the automation of this process. I had several thoughts how it can be implemented. The most obvious was creating simple Node.JS server and sending all data from investigate to server (further server will write all information to file).
Right now I'm totally concentrated on preparing release 2.0.0 with web support for this library, so can not say anything in advance. I would love to have automatic process, but I don't know whether its possible to get information about modules on compilation stage (obviously it's possible in runtime, but not really sure about compilation).
Hopefully I answered on your question and I hope some day I will simplify the process of generating packager content. If you have some thoughts how it can be done/achieved - feel free to share it here. I will be highly appreciate you for that!
But there is a relative advantage here: since the developers do this every time, they control what exactly was updated in the folder. And if many new dependencies were added, then obviously something is wrong with the code.
That's a good point!
Regarding the automation of this process. I had several thoughts how it can be implemented. The most obvious was creating simple Node.JS server and sending all data from investigate to server (further server will write all information to file).
I thought something similar. I'd imagine native modules etc might crash this though? But could be wrong.
I'd imagine native modules etc might crash this though?
@matt-dalton Could you elaborate more? I don't think it may affect, but maybe I'm missing something important
I'd just imagine that if you try and run your app using a node server without a proper mobile native build environment, something would crash?
I'd just imagine that if you try and run your app using a node server without a proper mobile native build environment, something would crash?
@matt-dalton I think it's possible to wrap sending info from investigate into if (__DEV__) statement. In this case you will send data only if you run app in development mode and uses metro-bundler and so on. And in release builds (or even in builds where JS bundle is already assembled and zipped within app) this code will not be included and it will not attempt to send anything to NodeJS server. Do you think it makes sense?