version control friendly extensions/modules/plugins

[jamie]

I wanted to share a feature idea that I think could make a huge difference for large companies using EspoCRM. It would be fantastic if extensions/modules/plugins could be managed in a way that’s version-control-friendly.

I know this might not be your favorite idea at first glance, but for bigger deployments, version control isn’t just a “nice-to-have”—it’s essential. Large teams rely on it to track changes, safely roll out updates, and coordinate across development, QA, and production environments. Without it, upgrading the core or extensions becomes a stressful, error-prone process.

Right now, my workflow involves spinning up a Docker image to test compatibility, installing directly on production, pushing the files into the repo, and then syncing the database the next day. It works, but it’s long, tedious, and a little nerve-wracking every time. If extensions could be managed in a version-control-friendly way, large companies could deploy confidently, roll back safely when needed, and generally avoid the “deployment anxiety” that comes with manual updates.

EspoCRM already handles entity definitions as migrations beautifully, and this would just extend that reliability to extensions. It would be a huge win for anyone running EspoCRM at scale. meaning more large companies will be likely to buy your exstentions meaning more money in your pocket

Thanks so much for considering this! Your work on EspoCRM is already amazing, and this could make life so much smoother for teams trying to manage complex deployments.

Warm regards,
Jamie

[yuri]

It can be interpreted differently. What is version control friendly. If it implies committing extension's source code and builds, then it's not the way. Like, we do not commit dependencies, we do not commit vendor, npm_modules. Some might do, but I would say that they use VC not for what it is intended.

Another question, that was raised before. Whether to use VC for deploying to production (committing and pushing the build). It's not the best approach, I don't think it's what large companies need.

The only proper solution I see, is having an extension repository (similar as one would use composer, npm). The extension name and its version will be committed only.

[yuri]

Other possible solution, that was already considered, is to have a designated drop-in directory, where extensions can be dropped in. All extensions dropped there will be installed/updated. Removed will be uninstalled. It's bit tricky to implement, but it's quite a simple solution that many may find handy. For deploying, one would use rsync.

[jamie]

I totally agree, an extension repository is probably the way forward. You are right that we do not want to include the extension files directly in the repo, and managing them via commands makes a lot of sense.

Would this approach also give us something like an espo.json similar to composer.json where we could manage versions and handle version conflicts more cleanly? That would be a huge help for enterprise deployments.

I say this because I have been battling the 9.1.9 to 9.3 upgrade for over 3 hours now and I am currently staring at a blank screen with little idea of what is broken. Doing this directly on production would not only be stressful, it could have serious consequences. I could easily be fired and potentially exposed to legal risk.

In my opinion, this is one of the only things holding EspoCRM back from being fully enterprise-ready. Having version-control-friendly extensions with proper version management would make large deployments much safer, predictable, and far less stressful.

Thanks again for considering this. It could be a game-changer for teams like mine trying to scale with EspoCRM.

Warm regards,
Jamie

[jamie]

Other possible solution, that was already considered, is to have a designated drop-in directory, where extensions can be dropped in. All extensions dropped there will be installed/updated. Removed will be uninstalled. It's bit tricky to implement, but it's quite a simple solution that many may find handy. For deploying, one would use rsync.

please gods no rsync. There is no versioning in that and its best left in the 80's we need proper version control for when, not if things go wrong i want to quickly undo it and go home for the night then come back on monday to fix it, not battle with problems all friday night

[yuri]

Then, there's no guarantee that exactly the same build will be created in the production. If we build locally, then build from the same source of truth on production, the artifacts may differ for some reasons.

[yuri]

By 'locally' I mean a designated server, not a local computed.

[jamie]

If there were an espo.json alongside composer.json to control all versions, I don’t see why it wouldn’t build the same thing each time. That is essentially the whole point of a versioning system.

Of course, there are sometimes differences between local and production environments, and that is actually an even stronger reason to build on production. Production might need a different version of a plugin or be set up with a different file / database system. Versioning and environment variables exist exactly to manage those differences. If all versions and environment settings are consistent, it should build the same result every time.

This is why having a proper version-control-friendly extension system is so critical. It would give confidence that deployments are predictable, reproducible, and safe, even when scaling across multiple environments.

After all, if production couldn’t reliably build the same system, no one would ever use package management or version control, and the internet would be absolute chaos 😅.