TriliumAlchemy - Initial CLI and rebranding for TriliumNext

[mm21]

I've recently published the initial CLI for TriliumAlchemy. It has some basic features like:

• Access Trilium configuration in a .env or .yaml file
• Tree export/import
• Database backup/restore

See the full documentation here: https://mm21.github.io/trilium-alchemy/tools/index.html

There are some more interesting features coming up like:

• Resync specified notes with specified template
  • Adds any missing child notes which are present in the template and/or reorders child notes as applicable
• Subtree dump to filesystem
  • Dumps specified subtree to filesystem, with notes stored as a .yaml metadata file (title/type/mime, attributes, child branches) and content file
  • Enables tracking of changes in source control: for example, easily determine exactly what changes you made since your last backup

Also, the project has been rebranded for TriliumNext - it will aim to keep up with any new TriliumNext features, while maintaining compatibility with Trilium.

[maphew]

This is interesting and timely. The tree export/import part especially as I've been struggling with how to keep in-app scripts in source control. Manual copy-paste circuits are tiring, so I tend to skip committing changes, which is a bad habit for me (to get back into!).

[mm21]

Thanks for the feedback! Keeping notes (especially scripts) in source control was one of the main motivations for the project.

I now have a system where I maintain my overall note hierarchy and infrastructure, including scripts, in source control (in the form of Python classes along with content files) and push to Trilium. In other words, it's a strict "filesystem-first" approach for infrastructure notes. This makes it easy to manage templates, themes, etc and reuse them across multiple Trilium servers.

The next step for my system will be keeping my non-infrastructure notes synced from Trilium to source control in a custom format, different than the .zip export. The format is designed to be diff-friendly in that, for example, moving a subtree will result in only a few lines changed in source control (adding and deleting branches) instead of a lot of moved files like the .zip export would have. The downside is that it won't be as human-readable since the hierarchy won't be recreated -- just a flat structure of folders by note id. Thus it's more of a "Trilium-first" approach while still being optimized for source control.

But I digress. I'm really interested in how others approach these things and how they might use the stuff I come up with.

[eliandoran]

@mm21 , if you design the format that would cause as few modifications as possible for source control, it would be interesting.

The approach we took, albeit finicky, is to simply extract the ZIP and commit its contents (we already do it for the user guide and technical documentation), but we'd be interested in something nicer.