A MonoRepo is what works best for us to ‘share code between projects’.
I can’t say or know if that works for you, too.
But to get an idea about this approach I’ve written this blog post:
1 Like
The MonoRepo sounds like a really good thing. I’m actually really scared about the different versions of Xojo though. I don’t want to have to always code in the lowest version of Xojo. One of the biggest challenges I see is the fact that I want to use Xojo2019r3.1 for my web app development as I’m not ready to move to Web2 and then what happens if I (or someone else) starts to use API2 calls in some of the shared code? I suppose that would be an issue with ANY shared situation - whether you use a repository or external items.
Finally you mentioned the danger of having multiple projects with shared items open and changes made to shared items in one project being overwritten by another. This is NOT a version control or repo issue. This happens without using external items. I’ve hurt myself multiple times doing this. At least in version control you can easily back out those overwrites if they happen!
Lots to think about but I think this is quite possibly the way to go…
Git has something called Submodules to share code between projects.
I have not used it personally. Though it is used at work where I work.
Here is some reference on it:
Fork has also good user interface support for it.
It’s not really nice. Submodule code is NOT pulled when the parent is pulled, and requires its own commits.
But the big problem with both this and MonoRepo is how Xojo organizes files. The project file is the single manifest for the project. If I include some of project A’s items in project B, project A tracks them with its manifest. If I were to add a class to a folder or module in project B, project A will not know about it. Same if I delete something. This problem is the single biggest hurdle to project time sharing. If Xojo would maintain manifests at each level (folder and module) then project A would include project B’s manifest and be done. You could modify from either project and the other would realize it when the project is loaded.
Isn’t that the point? You would need to open any of those new classes in A that you have added to B. Why would you want one project to know about every change to another project?
On the surface, yes. But if that one thing you’re sharing is a module, I’d imagine you want the module’s classes to follow along too, right? They won’t, since they are also stored in the project manifest. Same is true of a folder, which is also a useful thing to share.
That is the whole point.
I would not want it to auto pull the shared code. I want to decide when my solution is ready for it. Solution might be in old Xojo and shared code has moved on.
Note though you can set it up to pull. Its just not often done since then you loose the control of when its good to pull it for the given project.
Yes, but as is pointed out in Jurg’s blog post, if you have the shared module in both projects then it will get updated.
as long as the module is a single file, referenced in both projects, yes.
not if you’re adding new classes within the module (which will be new files) - then you need to get the project files in sync again once (e.g. by copy-paste).
Nothing is perfect - we have to cope with the fact that Xojo isn’t really designed for that kind of usage.
Yup. Once you know a couple of possible ways and their pros and cons you can decide what fits best with your project, situation, workflow.