Blog

v2.0.0 - Changing Defaults (MfGames Project Setup Flake)

2026-09-21T05:00:00Z

I like using mfgames-conventional-commit to handle semantic releases. However, a recent change to one of the supporting crates of that program caused a problem with building in pipelines, so I decided to make a breaking change to the flake, but also used that as an opportunity to add a few things.

The biggest one is mfgames-conventional-commits is not enabled by default. This means that it needs to be enabled as part of the flake:

{
  description = "Description for the project";

  inputs = {
    flake-parts.url = "github:hercules-ci/flake-parts";
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    rust-flake.url = "github:juspay/rust-flake";
    mfgames-project-setup.url = "git+https://src.mfgames.com/nixos-contrib/mfgames-project-setup-flake.git?ref=refs/tags/v1.4.2";
  };

  outputs =
    inputs@{ flake-parts, ... }:
    flake-parts.lib.mkFlake { inherit inputs; } (
      { withSystem, flake-parts-lib, ... }:
      {
        imports = [
          inputs.mfgames-project-setup.flakeModules.default
        ];

        # Configure mfgames project settings.
        mfgames.project = {
          enable = true;
          mfgames-conventional-commit.enable = true;
        };
      })
}

That should also speed up builds where the commits aren't required.

C# Changes

It looks like the change to Microsoft's C# guidelines are part of this release. This uses the .editorconfig settings from Microsoft's Runtime team. We were originally using the StyleCop from another Microsoft team, but this appears to be the “winner” for more consistent formatting.

It will take me a while to get used to _variable instead of this.variable, but I think it will be good in the long run.

Additional Changes

Since I was editing the file, I added a few things that were on my issue list:

Updated the base packages to 26.05 nixpkgs.
Added formatting of just files with just.format and the treefmt settions. This defaults to enable.
Added treefmt.enable (default true) to disable treefmt
Added just.format (default true) to format Just files. If enabled, treefmt will handle that.
Added treefmt.extraFormatters to provide custom formatting rules because it was annoying to add the shell formatter before I integrated it.
Added javascript.enable to add package.json and package-lock.json to the prettier ignore list.
Moved some JavaScript and TypeScript file extensions to be controlled by the respective format option (defaults to the enable flag).

I also found nixdoc after writing my own implementation of documentation. So I changed it to use that because I'm all for using other people's code to do something so I don't have to maintain it.

Configuration Arguments for v0.4.0 (MfGames Conventional Commit)

2026-09-20T05:00:00Z

We've been writing a number of CLI tools lately. When that happens, certain patterns start to become more obvious.

One thing is creating tables for output, which we just extracted into mfgames-cil-table into this program. There isn't any changes from that, mostly because we were extracting something we've been copy/pasting for a year.

The other change, however, is obvious. We've introduced the --config option. Previously, the configuration for mfgames-conventional-commit was hard-coded to be //.git/mfgames-conventional-commit.yaml. But, most of our other programs use --config to get rid of the hard-coding so we decided to do the same.

$ mfgames-conventional-commit --config .config/dev-mfgames-conventional-commit.json  version
 package_name  last_version  flatten_version  flatten_changed  detail_version  detail_changed
 default       0.4.0         0.4.0            false            0.4.0           false

If there is no --config, then this continues to work as normal. However, if one or more --config files are included on the path, those take priority.

Split Processing

This is one approach to handling a current limitation for this tool. At the moment, we only have one set of “update” commands in the configuration file. Those commands can be used to update versions inside assembly files or configurations. It can also be used to tag and push up releases, but there are times when one needs to update the versions before the build but do the tagging after the build.

To get around that, the --config can be used to have three files:

//.config/mfgames-conventional-commit.json
//.config/mfgames-conventional-commit-prepare.json
//.config/mfgames-conventional-commit-release.json

The first file contains the common rules for packages, how to find them, which ones exist. The second can be used for the actions that need to be done before the build such as updating version files.

$ mfgames-conventional-commit --config .config/mfgames-conventional-commit-prepare.json update

Then the third file can be used only in pipelines or for the release process to perform the actual tagging and uploading of binaries.

There might be a cleaner way to do this in the future, but at the moment, that's all we got.

Introducing mfgames-cli-table for Rust (mfgames-cli-table)

2026-09-18T05:00:00Z

One of the guiding principles of our development is the Rule of Three:

Three strikes and then you refactor.

In this case, a common pattern in our CLI's is generating tables. While this is relatively simple at the moment, it can quickly become complex. For example, we normally like our tables to be simple:

$ just example-basic
 name   value
 alfa   1
 bravo  2

But there are times when we want to dump it to Markdown or JSON:

$ just example-basic --markdown
| name  | value |
|-------|-------|
| alfa  | 1     |
| bravo | 2     |

$ just example-basic --json | jq
[
  {
    "name": "alfa",
    "value": 1
  },
  {
    "name": "bravo",
    "value": 2
  }
]

At the moment, there isn't much to this beyond what is displayed but we've created the same libraries in different languages and purposes, so we know that this has the potential of being more featured as time progresses. And it would be better to make it central now so we don't have to reinvent the wheel later.

Writing out to YAML
Adding/removing columns
Sort the output based on columns
Basic filtering
Right-align numbers in displayed tables
Dot-align decimals
Sending the table output to a file

New Version - v0.5.1 (Leicmin)

2026-08-14T05:00:00Z

Well, it's been four months since we introduced Leicmin. As far as we know, there is only one instance “in the wild” but that one instance has given us quite a list of issues, observations, and pain points.

Group Passwords

Probably the biggest one was how group passwords work. This is our attempt to handle providing accounts and passwords for static websites. Naturally, this is always a difficulty since we don't have a /auth/me endpoint that some sites have (mostly because we have no clue how to set it up), and OpenID Connect (OIDC) requires a bit of dynamic code (not to mention having Leicmin act as a OIDC provider, which is on the future list).

So that means we have an endpoint to generate htpasswd files directly which means the passwords are encrypted from the server down to the client, but it also means we have to decrypt the passwords in the server. This is in contrast to account passwords which are hashed with argon2 and not recoverable.

However, it wasn't obvious to some of the users that they also had to have their group password set for the htaccess file to work. So we “fixed” that by putting a notice on a couple key pages that give a link and dirctions to setting the password.

Obviously, once we figure out how OIDC can work with static sites, we'll provide that also. But, let's be honest, we aren't moving very quickly on this project.

Refactoring

This month's coding involved a couple nasty refactoring.

THe first was changing our template system. While we were using Minijinja for everything, it was getting a bit cumbersome (pain point on our case). We've switched Minijinja doing the page-level templating and generate the controls using Maud. It made it a lot easier to manage the code and catch typos.

But it also lead into our other refactor: challenges. Challenges were always intended to be part of the system. The idea of having a pluggable system for handling log in and registration was appealing, such as introducing an Anubis-like system for registration that automatically scales with load, or allow something to register with a SSH or GnuPG key instead of email has been one of our goals.

However, in the process of getting April's release, we ended up writing the login/registration process as a state machine. Well, switching to Maud made the checkbox to change password not work out well. So to do that, we migrated to challenges, which then encouraged us to also change our database strategy because of another pain point. So, now we can introduce a number of challenge steps into a generic work flow.

And that lead to us introducing SeaORM into the system. Originally we worked directly with SQLx and hand-written SQL statements but that got painful. We decided to go with SeaORM to reduce the boilerplate we were seeing in the code that made things a little painful.

Membership Expiration

One of the “we would really like this feature now” that we go was expiring groups. This is because some people pay directly and want access? Well, not entirely sure, but we implemented it. Since Leicmin is still pretty rough, the membership expiration has to be done via the CLI but it should work to let someone introduct temporary memberships.

Integration Tests

This isn't really useful for most people, but we figured out how to mock out the Patreon and Subscribe Star API, so we're in the process of also making sure those have some integration tests going because that section was always a manual effort.

Next Steps

Overall, there wasn't a lot of obvious changes in the code (except for the challenges). But, the code base is a lot easier to work with and hopefully that will set us up for the next few steps.

From the alpha tester, the biggest ones are:

Email registration
Password recovery
Single sign-on for Patreon and Subscribe Star

Our longer-term goals are still frustrating that they are needed, but there is clearly a desire for it:

Group membership limits (e.g., age verification)
Auditing (legal requirements of some of the age verification laws)
Geo blocking (so someone can do the Pornhub thing of banning entire states)

No idea of when the next time we'll circle around to this. Mostly depends on folks being interested, asking questions, or installing the still alpha-quality instance and try to use it. Other than that, we'll just keep plugging away.

Deprecations and Updates (MfGames .NET Libraries)

2026-07-04T05:00:00Z

It's been a while, but we had a productive week making changes to the library.

Deprecations

One advantage of having a monorepo of all of the MfGames packages is being able to link everything together without doing a railcar shuffle when one package requires another and another and takes half a day to update a dependency. The drawback is that it makes it harder to abandon one of the libraries. Today is one of those days where we realize there are three libraries that need to be dropped from active development.

MfGames.Identifiers was a good idea at the time but then we found that other libraries can handle the same goals and we don't have to maintain ours. Also, working with source generated files is painful so we are thinking those libraries are a better choice for now.
MfGames.Nitride.SpectreConsole was an attempt to funnel Serilog output through SprectreConsole so we could get progress bars playing well with output for MfGames.Nitride. It ended up being cumbersome and, while it worked, it also had some minor quirks that were irriating enough that we just gave up on the idea of progress bars entirely instead of trying to fix it.
MfGames.Serilog.SpectreExpressions was the underlying library for the MfGames.Nitride.SpectreConsole. This ended up being a mirror of the existing expressions library from Serilog because the original was sealed and couldn't be extended without copying the wheel. It also didn't have the full ability as the original library because it was hard to maintain code that isn't ours while needing to track any vendor changes. So when MfGames.Nitride.SpectreConsole was deprecated, so was this.

Now, we don't want to abandon old code entirely, so we moved those projects from the //src directory into the //attic/ directory. That way, the code remains available in case we find another use of that. This also means that those projects will “bit rot” in that they won't be refactored and maintained with the code in //src/, //tests/, and //examples/. The more time passes on, they will become less useful as code until we clean out the attic, which may be years from now.

Package Updates

In addition, we've done a round of updates to keep everything running smoothly and handle some vulerability warnings in our dependencies. Overall, this was a simply process except libraries dealing with:

CLI
MfGames.Nitride.IO

For the CLI, we use System.CommandLine as the base of our MfGames.ToolBuilder library, which is basically an opionated setup that uses Serilog, Autofac, and dependecy-injected commands. When moving from version 2.0.0-beta8 (it was in beta for over five years) to 2.0.9, there were some drastic refactoring that needed to be done. This resulted in all the CLI commands (MfGames.ToolBuilder and MfGames.Nitride) having a breaking change since the signatures changed across the board. There were relatively few dependencies on this, but they were all bumped to major versions.

For the other libraries, this was a feature (0.x.0) update because of potential side effects we haven't been able to identify.

MfGames.Nitride.IO

The other change was MfGames.Nitride.IO. In specific, we changed how the ReadFiles operation worked because of real-world difficulties. Most of our IO operations are based on the excellent library, Zio which gives use UPath which simplifies path processing, virtual file systems which makes test writing a lot easier, and remapped structures that let us treat a folder as /sources/allegro as / so our Fedran can treat each project Git repository as a root folder, which simplifies logic. We also like using recursive globbing (ones that use ** to recurse into dirctories in addition to * for matching at a given level).

The problem is that Zio doesn't support globbing natively. So our original implementation was to iterate through every file using Zio, then compare it against the glob.

For simple cases, this was fast. However, when we're doing a search like /src/**/chapter-*.md in a project directory, this also processed through /node_modules, .direnv/, and target/ folders which have a staggering amount of files that we don't want.

Nowe, we have both include and exclude patterns in an ordered list. For each one, we parse the pattern and attempt to do some simple heuristics with the root comparisons before we devolve into the “grab everything to compare it”. What this means that for /src/**/chapter-*.md, we go into /src before we grab everything. The other massive folders are looked at, and the code chooses not to go into it. If there are no ** in the pattern, this will give us a rather prescise scan which is faster than before.

// Old version
ReadFiles readFiles = Resolve<ReadFiles>()
  .WithPattern("/chapters/chapter-*.md");

// Old version without using the .With* methods.
ReadFiles readFiles2 = Resolve<ReadFiles>();
readFiles2.Pattern = "/chapters/chapter-*.md";

// New Version
ReadFiles readFiles = Resolve<ReadFiles>()
    .AddIncludePattern("/chapters/chapter-*.md");

To keep the conventions from .gitignore and other files, if you give the pattern as *.txt, we change it to /**/*.txt.

Which leads to the exclude patterns. /** effectively goes back to the old code of grabbing everything and comparing it. But if you then add an exclude pattern (ideally without a **), it will stop processing the includes if it already knows it will be excluding it.

ReadFiles readFiles = Resolve<ReadFiles>()
    .AddIncludePattern("/**/chapters/chapter-*.md")
    .AddExcludePattern("/node_modules")
    .AddExcludePatternList(
        "/.direnv",
        "/target");

This will eventually lead up to being able to pass in .gitignore directly into the code, but we want the code base to settle (e.g., use it for awhile) before we add that.

There is also a .WithPatternList() which takes a list of a typesafe collection, but that's a more edge case and if you need that, then you might want to look at our tests for examples of how to write those.

Some Quality of Life Changes (Fiss)

2026-06-13T05:00:00Z

It's been over a year since there were any major changes to fiss, mostly because it did the minimum functionality we wanted and there are no other reported issues. However, that isn't to say it was perfect or not filled with bugs (you know, like fiss group list throwing a panic because it was never implemented).

Since we had a little time to work on something, we decided to address some quality of life issues that will hopefully make it more pleasant.

Progress Bars

When fiss is pointed to large collections of repositories, like Dylan's fiction sites, there are hundreds of repositories. When running fiss cache sync, it would take significant time to run because it walks through every server, group, and project that user is subscribed to. For us, we have hundreds and this takes a while because our server isn't that fast.

To give some feedback, instead of showing nothing for 30-90 seconds, we implemented a nested progress bar that shows the process.

$ fiss cache sync
sync_server_by_name server_name="mfgames"                                                                 3.9s
  ↳ sync_group_by_names server_name="mfgames" group_name="fedran-sources"                                 1.8s
    ↳ sync_project_by_names server_name="mfgames" group_name="fedran-sources" project_name="a-simple-cog" 0.1s

This only shows up if the command is entered into a terminal but it can be disabled with --show-progress never. In addition, always forces it to run even outside of a terminal, and auto does its best guess to determine if it is attached to a terminal or not.

The output isn't “pretty” but it is functionality for our purposes. The output is sent to “standard error” so redirect a command to get the JSON output won't be polluted by the output, even if --show-progress always is used. (Likewise, all console logging is also always sent to standard error for the same reason.)

More Intelligent Syncing

The above was written to help debug the one feature we were working on: being more graceful about how we sync our information with the forge. Previously, the only way to get a fresh list of issues was to use the fiss cache sync command which took some time.

$ time fiss cache sync --forge-sync always

real	0m46.598s
user	0m5.533s
sys	0m0.397s

If you can't guess from the spoiler, we have the same options: auto, never, and always implemented here.

$ time fiss cache sync --forge-sync never

real	0m3.127s
user	0m3.077s
sys	0m0.104s

It still walks through the servers and projects, but shaving forty seconds because it doesn't have to do API calls to the forge is a significant time savings.

When using auto, the default, the system now keeps track of the last time a server, group, or project was syned. It only syncs if the server or group hasn't been refreshed in a week or the project hasn't been refreshed in a day.

time fiss cache sync

real	0m3.126s
user	0m3.076s
sys	0m0.103s

That should make that aspect more useful.

Refresh On List

The third and final change was implementing syncing when running the list command. As said above, the only way to get new issues from the web was to run fiss cache sync. Now, fiss cache list also refreshes but it is more intelligent about it based on the scope.

For example, if only a project is requested, then it only syncs that project which takes considerably less time to implement (1-2 API calls at this point and usually under 100 ms with our current setup). However, if a group is requested, then it will only sync all the projects under that group.

fiss list --group fedran-sources
 id                                                title                                               state  assigned
 mfgames/fedran-sources/allegro/7                  Get automatic versioning working                    open
 mfgames/fedran-sources/allegro/6                  Get it sent to the copywriter                       open
 mfgames/fedran-sources/allegro/5                  Get it sent to the development editor               open
 mfgames/fedran-sources/allegro/4                  Create a cover a cover                              open
 mfgames/fedran-sources/coins-for-your-troubles/1  Chapters 12 and 13 need an editing pass             open
 mfgames/fedran-sources/flight-of-the-scions/2     Go through and update the various content warnings  open
 mfgames/fedran-sources/flight-of-the-scions/1     Make the book public                                open

And if fiss cache list --server mfgames is used, then it will sync all the groups and projects on that server before showing the list. Since this is automatic done (baring the use of --forge-sync), then fiss list will always get the most recent copy of the tasks that need to be done.

As, if the command is used without options, it picks up the project from the current Git repository which means fiss list is useful when inside that project's directory.

$ cd fiss
$ time fiss list
 id                    title                                                                       state  assigned
 mfgames/fiss/fiss/16  Get flake working as input for another flake                                open
 mfgames/fiss/fiss/15  Do not show archived projects by default                                    open
 mfgames/fiss/fiss/13  Implement subscriptions                                                     open
 mfgames/fiss/fiss/11  Allow for --body/-b to edit the body text                                   open
 mfgames/fiss/fiss/10  Show information after creating a new issue                                 open
 mfgames/fiss/fiss/8   Show progress while syncing with server                                     open
 mfgames/fiss/fiss/7   Refresh servers, groups, and projects periodically                          open
 mfgames/fiss/fiss/6   Cache foregejo API handle                                                   open
 mfgames/fiss/fiss/20  Handle fiss list fetching from empty set                                    open
 mfgames/fiss/fiss/21  Better handling when a server is removed from the config                    open
 mfgames/fiss/fiss/22  Allow output of URL or ID when creating a new issue                         open
 mfgames/fiss/fiss/23  Configuration option for how frequently to get server, groups, or projects  open
 mfgames/fiss/fiss/24  Allow sync from list to retrieve new groups and projects found              open
 mfgames/fiss/fiss/25  Change sync to be based on *_cache instead of by name                       open
 mfgames/fiss/fiss/26  Implement issue-level syncing                                               open
 mfgames/fiss/fiss/27  Figure out why Radicle will not sync                                        open

real	0m0.036s
user	0m0.030s
sys	0m0.009s

Future

We still use this project almost every day to manage our lists, but since we're the only people appearing to use it, features will show up as we need them or something annoys us. As usual, reporting issues is already appreciated but since we have to periodically disable registration on our forge, we'll be looking into better ways of submitting issues, having discussions, or getting patches. Until then, use Dylan's contact page or contact@mfgames.com.

v1.0.0 - Breaking Changes (MfGames Writing Setup Flake)

2026-04-16T05:00:00Z

As the chained updates go through, we've managed to update this project to use the new options-based format of mfgames-project-setup-flake.

This release changes a few things:

We are now switching to semver with this being tagged as v1.0.0
Moving from the mkConfig to a NixOS-style configuration
Embracing Justfile as the default build process

Importing

Importing is slightly differen than before. Inputs should include the tags:

flake-parts.url = "github:hercules-ci/flake-parts";
mfgames-writing-setup.url = "git+https://src.mfgames.com/nixos-contrib/mfgames-writing-setup-flake.git?ref=refs/tags/v1.0.0";
mfgames-writing-setup.inputs.nixpkgs.follows = "nixpkgs"; # Optional

This flake needs to be imported into the module:

  outputs =
    inputs@{ flake-parts, ... }:
    flake-parts.lib.mkFlake { inherit inputs; } {
      imports = [
        inputs.mfgames-writing-setup.flakeModules.default
      ];

While we haven't figured out how to get this to play with flake-utils, we've changed our flake to use flake-parts which gave us a better framework for figuring out the options. As a note, configuration is done outside of the perSystem, but the results (config.mfgames.writing) are provided inside perSystem.

      mfgames.writing.enable = true;

      perSystem =
        { config, pkgs, ... }:
        {
          devShells.default = pkgs.mkShell {
            packages = [ ] ++ config.mfgames.writing.packages;
            shellHook = config.mfgames.writing.shellHook;
          };
        };

Project Setup

If you notice, this no longer requires adding the mfgames-project-setup-flake settings, this flake will now automatically include that unless you need to specifically override it. However, you don't have to import the project setup if you want to use its current functionality, such as using mfgames.project.reuse to license your work:

      mfgames.project.reuse.enable = true;
      mfgames.writing.enable = true;

At the moment, there is no specific settings under mfgames.writing other than enable. The above example still imports everything you need to set up mfgames-writing-js except that library itself. That is going to be the next change, to automatically package everything including the JS libraries, but not quite yet. Until then, you still need to set up your package.json to include those projects. When that does it, this will be another breaking change because 99% of the time, anyone using this flake is also going to be using mfgames-writing to build the projects.

Semantic Versioning (Leicmin)

2026-04-12T05:00:00Z

Six months ago, we started on a new project called Leicmin to provide an application for managing members of subscriber groups along with a naieve implementation of age verification checks for those who enjoy the “spicer” side of creation.

We were lucky to have an early adopter who helped us iron out some of the more egregarious bugs that were in the application, but there is a still a long way to go. But it is nice to have an instance “in the wild” as it were.

This also marks the point where Lecimin is going to have proper semantic versioning, at least for releases. This is important because there was a lot of going back and redoing Postgres migrations which would then require a full install to work.

Moving forword (e.g., after v0.3.0), the retroactive database changes will only happen between one tag and another. So, if you do use it (and let us know if you want to), stick with version tags instead of going directly against main.

Breaking Changes (MfGames Project Setup Flake)

2026-04-05T05:00:00Z

In the beginning, I wanted to use NixOS options with the flake instead of using a mkConfig function to generate the files and shell hooks. But, due to complexities and struggling with Nix, I couldn't figure it out. But, after two years of working on it, I finally got a working implementation that uses the cleaner approach of options.

So that means instead of using mkLib, using mfgames-project-setup-flake means adding it as an input (as before), importing the model (that's new), and then using configuration settings (those are new).

The flake still needs to be added as an input:

inputs.mfgames-project-setup.url = "git+https://src.mfgames.com/nixos-contrib/mfgames-project-setup-flake.git";

It also now has a module which needs to be imported and then configured using the same syntax that most other configurations are used.

imports = [
    inputs.mfgames-project-setup.flakeModules.default
];

mfgames.project = {
    enable = true;
    rust.enable = true;
};

Then, in the mkShell call, the various hooks are called to integrate it.

devShells.default = pkgs.mkShell {
    packages = []
        ++ config.mfgames.project.packages;

    shellHook = config.mfgames.project.shellHook;
};

I also refactored how options where documented and displayed. It is now a script-generated file that is rebuild during the build process so I don't have to worry about getting it stale.

Versions

The old version is now v0.5.0 with the new version current at v1.1.0.

Breaking Changes

Since this is a really breaks existing setups, I'm also taking the opportunity to make other changes that have popped up in the last few years that I didn't want to be disruptive but I think will benefit the project in the long run.

REUSE

Probably the biggest one is stumbling onto REUSE Software and seeing a more nuanced (though complicated) specification for handling licenses that differ across files even in the same project. That is osmething I couldn't do but it resolved a number of issues I had after trying to integrate mfgames-writing-project-setup which is less code-oriented and more prose-oriented. After mulling over it, I decided to remove looking over the differencesand reasoning, I decided to integrate REUSE into the flake and remove the existing licensing handling.

This means removing the following keys from before:

creativeCommonsAttributionShareAlike.enable
creativeCommonsAttributionNonCommercialShareAlike.enable
mit.enable
mit.filename

And replacing it with:

mfgames.project.reuse.enable
mfgames.project.reuse.ignore-dot-config
mfgames.project.reuse.annotations

The most complicated part is that REUSE is “picky”. It requires every file to be properly licensed, so I introduced the ability to create the REUSE.toml annotations from the flake file which will be suppelemented by the automatic annotations from the generated files this flake produces.

mfgames.project.reuse.annotations = [
    {
        path = [
            "docs/**/*.md"
            "news/**/*.md"
            "README.md"
        ];

        SPDX-FileCopyrightText = "2026 Dylan Moonfire <contact@mfgames.com>";
        SPDX-License-Identifier = "CC-BY-4.0";
    }
    {
        path = "src/**/*.nix";
        SPDX-FileCopyrightText = "2026 Dylan Moonfire <contact@mfgames.com>";
        SPDX-License-Identifier = "MIT";
    }
];

I also consider most of the contents in .config to be generated files, so an annotation is added to mark all of those files as public domain unless turned off with mfgames.project.reuse.ignore-dot-config = false;.

Developer Certificate of Origin

I modified the setup so it adds the “Signed-off-by” to the bottom of Git commit messages if `mfgames.project.developerCertificateOfOrigin.enable = true".

Rust

I prefer a more vertical style of formatting in my code. That usually means I want braces on their own line for almost everything, including if statements. This was “on the same line” in the previous version, but now it defaults to braces on their own line.

Non-Breaking Changes

I found a consistent logging program that gives useful messages: gum. While the colors are not exactly my thing, I find it useful to have the same type of messages across the board. So you'll see a variety of functions now use that for logging, when easily done.

Project UUID

A few years ago, I stumbled onto a blog post about creating a “power ID” for projects. In effect, a UUIDv7 that uniquely identifies a project and make it easier to distinguish projects of the same same (such as Gemini the Protocol, Gemini the Cryptocurrency, and Gemini the LLM). That is why you see 019530bd-5065-731f-925b-3961eb7aa613 in almost every blog post and article I write about mfgames-project-setup-flake.

Since I've embraced that, I also modified this project to generate one if there is no .config/project-uuid.txt present in the project. This is intended to be checked in since it shouldn't change.

This functionality can be turned off with:

mfgames.project.project-uuid.enable = false;

Shell Formatting and Checking

I also recently started using shfmt and shellcheck for my shell scripts. I've introduced some options for this.

mfgames.project.shell.enable
mfgames.project.shell.check
mfgames.project.shell.format
mfgames.project.shell.includes

check and format use enable if not defined. And enable defaults to mfgames.project.enable.

If check is true, then just check-shellcheck or just check will run that utility against the files.

If format is true, then just format and just format-shfmt will format the shell script, as will commiting a file.

A Slew of (Breaking) Fixes (MfGames Writing Tools)

2026-01-17T06:00:00Z

We've just pushed up a new version of mfgames-writing-js. Naturally, this started with the usual process of doing a little housekeeping, and bringing packages up to date.

The main focus was to fix two bugs:

Unfortunately, we had to make a breaking change and bumped the major version of some of the packages, which also requires at least a minor update to the other changes to pick up the new version ranges.

And then what followed was an embarassing set of NPM package updates as we tried to get everything working consistently and feeding into dependent projects like fedran-writing-setup-flake which is a mass setup scrip for all the writing projects on fedran.com.

Along the way, we also introduced --log-level support so mfgames-writing-format build wasn't quite as noisy.

Short Version

If you use mfgames-writing-js, update all your packages to the latest and things should Just Work™. If they don't, please don't hesitate to report an issue or contact Dulan

Pipeline Exclusions

Added an exclude to pipelines in the same pattern as the content elements:

contents:
  - element: chapter
    source: pipeline.md
    pipeline:
      - module: "@mfgames-writing/hyphen-pipeline"
        exclude:
          editions: [docx]

This caused a difficulty with an undocumented element in hyphen-pipeline which allowed for a regular expression to ignore certain words that caused problem with hyphenation. This was moved to exclude.regex.

contents:
  - element: chapter
    source: pipeline.md
    pipeline:
      - module: "@mfgames-writing/hyphen-pipeline"
        exclude:
          editions: [docx]
          regex: ["^bob$"]

Because this changed some projects in use, it was treated as a breaking change and bumped the version.

Section Breaks

When we write in Markdown, we always use *** for section breaks.

---
title: Chapter One
---

Something happened.

---

After the break.

However, proejcts like mfgames-writing-setup-flake use prettier which always converted the *** into --- which is also a proper Markdown rule (which we use as a section break in stories).

Due to interactions with SmartyPaths, those --- were helpfully turned into an em-dash (—). We put in a little patch code that an em-dash on a line by itself is considered a rule for section breaks and turned back into ---.

Output Directory

Another thing that we've done with mfgames-writing-setup-flake is put all the output files into the build/release folder to keep them out of the root directory of the repository. But there was a little but where .docx files couldn't handle that.

We fixed it.

Logging

Also, it was a little annoying having so much data that we added a --log-level to control output. It defaults to info but can also be trace, debug, info, warn, and error.

Updating Dependencies (MfGames Conventional Commit)

2025-12-05T06:00:00Z

Just a little maintenance update.

Updated the Nix flake from 25.05 to 25.11
Updated Rust to the 2025-12-05 nightly
Updated various dependency packages
Bumped the version to 0.3.0

Nothing really fancy, just housekeeping.

Making It Useful (MfGames Conventional Commit)

2025-08-12T05:00:00Z

We wrote mfgames-conventional-commits to solve a small itch of wanting to be able to calculate version numbers based on Conventional Commits but only for commits that touch specific directories. That way, a change to MfGames.IO would bump that version up but not touch the versioning for MfGames.Nitride in the same monorepo. For the most part, it was to allow the CIL projects to have different versions as they all had different lineages before they were combined.

As things go, we always intended to polish and expand on the tool but other things got in the way. But then D. Moonfire was working on Git For Authors and realized they didn't have a good solution for calculating version numbers of novels. Since we already had this tool, we spent a few days making it more useful and capable for single package projects and require less overhead to configure it.

Simplified Setup

The configuration file goes into //.config/mfgames-conventional-commit.json as usual, but setup has gotten significant easier. we added a defaults section that applies to every project along with substitutions for packages with {package} that allow each pack to have their own directories.

{
  "$schema": "https://mfgames.com/mfgames-conventional-commit-rs/schemas/v0.json",
  "defaults": {
    "tag_prefix": "{package}-",
    "directories": { "include": ["src/{package}"] },
    "files": { "include": ["src/{package}/**/*"] }
  },
  "packages": {
    "MfGames.Cryptography": {},
    "MfGames.DI.AutofacExtensions": {},
    "MfGames.Gallium": {},
    "MfGames.IO": {},
    // There is more here
    "MfGames.ToolBuilder.Tables": {}
  }
}

It used to be we had to have the tag_prefix and files elements in each one with a customization per project to include the path. Now, {package} can be used to substitute the package name and defaults to apply to any package that doesn't have settings underneath itself. In the future, we'll have some configuration that will scan the //src directory for the package names, but not this round.

Version Numbers

We also have two variants of version numbers based on usage. The first is the “flatten” version which calculates the most relevant major, minor, or patch version and applies it to the latest found tag. So if you have a “feat”, “fix”, “fix” on 1.0.0, it would be “1.1.0”. In contrast is the “detail” version which applies the version one at a time. So if you had the same “feat”, “fix”, “fix” on 1.0.0, the result would be “1.1.2”.

Most software projects seem to make a conscious decision to bump up the version. With semantic releases, the versioning is done on the pipeline. For a long time, we used “flattened” as the basic approach since that is what Semantic Release did. However, with novels and the like, sometimes they go out without the pipeline running and it is useful to make sure new versions show up; hence the use of “detail”.

This also resulted in a slightly different output for the mfgames-conventional-commit version command:

$ cd src/MfGames.IO
$ mfgames-conventional-commit version
 package_name  last_version  flatten_version  flatten_changed  detail_version  detail_changed
 MfGames.IO    2.7.0         2.7.0            false            2.7.0           false
$ mfgames-conventional-commit version --all | head -n 5
 package_name                        last_version  flatten_version  flatten_changed  detail_version  detail_changed
 MfGames.Cryptography                14.7.0        14.7.0           false            14.7.0          false
 MfGames.DI.AutofacExtensions                      0.0.1            true             0.0.1           true
 MfGames.Gallium                     3.6.0         3.6.0            false            3.6.0           false
 MfGames.IO                          2.7.0         2.7.0            false            2.7.0           false

Because we're fond of changing format as needed, so it can also dump a JSON or Markdown version. And all logging is sent to stderr, so piping can work properly.

$ mfgames-conventional-commit version --json | jq
[
  {
    "package_name": "MfGames.IO",
    "last_version": "2.7.0",
    "flatten_version": "2.7.0",
    "flatten_changed": false,
    "detail_version": "2.7.0",
    "detail_changed": false
  }
]
$ mfgames-conventional-commit version --all --format markdown | head -n 5

package_name	last_version	flatten_version	flatten_changed	detail_version	detail_changed
MfGames.Cryptography	14.7.0	14.7.0	false	14.7.0	false
MfGames.DI.AutofacExtensions		0.0.1	true	0.0.1	true
MfGames.Gallium	3.6.0	3.6.0	false	3.6.0	false
MfGames.IO	2.7.0	2.7.0	false	2.7.0	false
MfGames.Locking	2.5.1	2.5.1	false	2.5.1	false

Updates

Another useful feature is the ability to perform updates if the version number changed. This is used to define an updates element in the configuration file:

{
  "$schema": "https://mfgames.com/mfgames-conventional-commit-rs/schemas/v0.json",
  "defaults": {
    "updates": [
      { "script": "npm version {detail_version} --no-git-tag-version" },
      { "script": "git tag v{detail_version}" }
    ]
  }
}

As you can see from above, the command will change the NPM version and create a Git tag. If always_run is set to true, then it will run every time it is called, otherwise it will only run if the Git tag doesn't match the calculated tag.

The main reason for this is because then we don't have to write a hundred plugins for different systems. You can just write the script to do it, call another program, or just write some output. Anything a shell can do, this can do.

Inferred Package

One of the more annoying things is that we couldn't figure out the package name from the current context. For the most part, that didn't mean much since we could always provide --package package-name, but we found it useful enough that we made the tool figure out the patch from the directories attribute above. This also handles {package} substitutions, so it is generally useful.

Both the version and update commands also take an --all which means all packages in the project instead of --package package-name for an arbitrary package, or either of these to guess it from the directory.

Sane Defaults

Finally, we added a sane default if the //.config/mfgames-conventional-commit.json file is missing, or it doesn't have many settings. This assumes the entire directory is a single package called “default” and it uses a “vX.X.X” tag to represent versions.

Future Steps

This is a secondary project for us. Obvious, if we have an itch and it doesn't do something we want, we'll add it. If there are any issues that would be really useful or if you come up with something useful for the project (that is in scope), report or comment on it and we'll see about implementing it.

Introduction `@mfgames/nine-degrees-below` (Nine Degrees Below Palette)

2025-06-26T05:00:00Z

While working on Fedran covers, we've stumbled on Nine Degrees Below's LCh color palette and fell in love with it. So much we wanted to use it for both the cover designs and the design on the website. This meant generating slightly differently arranged GPL palette files than what is provided on the link. We also needed CSS variables for our website.

Along the way, things got more complicated and we ended up with this: a Node package that has “design tokens” as generated by Style Dictionary, CSS and Sass variable files suitable for using with Webpack and ESBuild, and a few other bits and bobs.