Diving deeper into the idea in #3027 I think it would be nice to define how to structure the code to split it into independent packages.
These are the independent modules I’ve identified that can be implemented as opt-in plugins:
- Core: The camera component. Take picture and record video
- MLKit Core: Core of MLKit related features
- Face Detection (Plugin)
- Bar Code detection (Plugin)
- Text Recognition (Plugin)
- … other features
I’ve worked with this kind of monorepo before, and I strongly suggest using Lerna + Yarn workspaces and TypeScript.
Bob the builder is an amazing tool to scaffold each module and it even provides a sample apple for each module to help developing on it and to make end-to-end tests.
Creating an npm org to group all the different modules would be ideal, the original
react-native-camera can be kept as the core. It is common when migrating to an org to use the original module as a proxy to the new one under the org, but that could be an issue with react-native’s autolinking.
Plugins can be attached to the camera component as children like suggested by @renatobenks, and configured both globally (most likely with a global context component) and with props when passed to the specific Camera component.
Moving into this kind of repo structure can be challenging and the most viable way to do it is to freeze changes to the old structure until the new structure is ready to go. Before freezing all pending PRs should be merged or closed.
It would be nice to make mayor decisions like #1029 to take them into account before changing the project structure and/or freezing the old code.
Please share your thoughts!