D. Moonfire

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.

Introducing Fiss (Fiss)

2025-02-20T06:00:00Z

In a world where there are a lot of tools to manage tasks, this is one more. Fiss is a CLI-based tool that exposes issues from forges (such as Foregejo) in a task-centric interface. This tool is inspired by Taskwarrior and is designed from the ground up with the intent of using multiple forges, groups/organizations, and projects as the high-level organization.

Justification

There are a lot of tools that do the same thing, managing tasks. As well-designed or powerful as they are, the main reason for writing Fiss is that they didn't work the way we needed them too.

There Is More Than One Way To Do It

— Larry Wall

Fiss does, but isn't to say we haven't tried to find another alternative. We have, for many years and many attempts to find the “one perfect tool” for us.

Taskwarrior

Taskwarrior is very powerful, but it doesn't work well outside of the CLI. In our experience, the web services for sharing tasks across machines work fairly well, but are cumbersome to set up.

The support on Android, our current phone operating system, is relatively poor.

In many cases, the other services end up packaging Taskwarrior inside them to perform the various calculations because Taskwarrior is also very complex and not well documented. At least, it seems that way since there are not many Taskwarrior-compatible alternatives. Even the Android packages we found effectively said they packaged Taskwarrior inside them.

iCalendar

We love iCalendar (.ics) files. With our local NextCloud server, it is great for handling a lot of our common tasks.

Working with a Linux CLI and .ics is difficult. We've tried a number of different ways over the years and haven't found anything that works the way we want. Or consistently.

Introduction

Right now, this tool is barely alpha. It requires a lot of manual editing of the configuration file as documented on the website.

Adding a Server

Adding a server is pretty simple. A server has a short name, which is used by the tabular output and to reference the server.

export FISS_SERVER=mfgames
export SERVER_URL=https://src.mfgames.com
#TOKEN=the token from Forgejo
fiss server add -s $FISS_SERVER --url $SERVER_URL --token $TOKEN
fiss server add --url $SERVER_URL --token $TOKEN

It will also automatically pick up FISS_SERVER from the environment. Same for FISS_GROUP and FISS_PROJECT below.)

export FISS_SERVER=mfgames
fiss server add --url $SERVER_URL --token $TOKEN

It can be listed, not that it helps much.

$ fiss server list
 server   url                             forge    updated_seconds
 mfgames  https://src.mfgames.com/        forgejo  2025-02-15 13:15:41

All lists can be dumped as JSON:

$ fiss server list --json | jq
[
  {
    "server": "mfgames",
    "url": "https://src.mfgames.com/",
    "forge": "forgejo",
    "updated_seconds": "2025-02-14 18:04:54"
  }
]

They can also be dumped as Markdown:

$ fiss server list --markdown

server	url	forge	updated_seconds
mfgames	https://src.mfgames.com/	forgejo	2025-02-14 18:04:54

The reason servers are considered first-class is that we wrote Fiss to handle multiple forges at the same time. We have multiple Forgejo instances. Eventually, this tool will be expanded to also include iCalendar, SourceHut, GitLab, and GitHub. Potentially, one could have multiples of those also, so servers are part of the organization structure.

Groups

On a server, you have groups. Right now, users don't work yet, but groups are fine.

$ export FISS_GROUP=fiss
$ fiss group add -s $FISS_SERVER -g $FISS_GROUP

We decided to call the organizations and users “groups” because our “day job” uses “organizations” and it is really hard to spell that consistently while typing at speed. Using “groups” is relatively generic and is sufficient for our needs.

Projects

Projects are the third level of organization. Creatively, they are done the same way.

$ FISS_PROJECT=fiss
$ fiss project add -s $FISS_SERVER -g $FISS_GROUP -p $FISS_PROJECT

Caching

To avoid overloading the forges, we cache the issues. In the future, we periodically will refresh the data, pick up new issues, close others. Right now, you have to manually pull in the data.

fiss cache sync

⚠ Since there isn't a lot of elegance at this point, this will pick up all projects underneath a group and also download every single issue from those projects. That includes closed and open. So, it would not be a good idea to point this at any project that has a large number of issues.

There is also going to be controls for automatically subscribing to new projects, so you can choose to get all of them, or only require specific ones.

Issues

Once everything is synced, then the commands are pretty simple. To list issues:

fiss list -s $FISS_SERVER -g $FISS_GROUP -p $FISS_PROJECT

If the command is run inside a Git repository (any inner directory can work, it will find the Git root), it will attempt to pick up the server, group, and project from the remotes. Also, if there is a distinct name for a project, then -p $FISS_PROJECT would be sufficient.

If you want to list all projects inside a Git repository, the list command supports globbing for servers, groups, and slugs. This means fiss list -p '*' will show all projects no matter where you are in your directory structure. Also, multiple globbing can be done with colons, such fiss list -p fiss:mfgames-cil will list all fiss and mfgames-cil projects.

From this point on, we're going to assume you are in the Git directory or have FISS_SERVER, FISS_GROUP, and FISS_PROJECT set appropriately.

fiss list

Creating a new issue also relatively simple and there really isn't that much. The rest of the commands are assuming you are in a Git directory, or you exported

$ fiss add -t "Name of project"

This creates an issue. Right now, it just says nothing but it will eventually give you a useful message or at least emit the issue number.

There are commands to open and close tickets using -i or --issue with the issue number.

fiss issue close -i 3
fiss issue open -i 3

Example

So far, even at this basic state, it is fairly functional.

cd fiss
fiss list --markdown

id	title	state
mfgames/fiss/fiss/6	Cache foregejo API handle	open
mfgames/fiss/fiss/7	Refresh servers, groups, and projects periodically	open
mfgames/fiss/fiss/8	Show progress while syncing with server	open
mfgames/fiss/fiss/9	Teach ‘cache sync’ to only sync certain projects	open
mfgames/fiss/fiss/10	Show information after creating a new issue	open
mfgames/fiss/fiss/11	Allow for –body/-b to edit the body text	open
mfgames/fiss/fiss/12	Update to new version of foregejo API	open
mfgames/fiss/fiss/13	Implement subscriptions	open
mfgames/fiss/fiss/14	Do not show closed issues by default	open
mfgames/fiss/fiss/15	Do not show archived projects by default	open
mfgames/fiss/fiss/16	Get flake working as input for another flake	open

You can also see this list on our forge.

Future

So, we think this tool has potential. We'll be using it and improving it slowly as we find pain points or things where it doesn't work. At minimum, the goals are:

Add, create, and list tags on issues
Implement milestones
Implement sub-projects
Be able to edit other elements of the item (fiss edit -i 3)
Be able to open up the page from the CLI (fiss web -i 3)
Get it working properly with NixOS flakes
Be more elegant in retrieving issues
Implement the subscription control so we can decide to include 100s of projects automatically

Moved Repository to MfGames (MfGames Writing Tools)

2025-01-12T06:00:00Z

It's been a few years and this project has moved homes a few times. We realized in the last day that we haven't been paying attention to where this project was housed compared to when we abandoned GitLab because of their enshittification.

The current home for mfgames-writing-js is now on src.mfgames.com and it now has a fancier home page.

We are going to spend a little time spurcing up the library, bringing it to a modern version of TypeScript, and infrastructure. This will be considered a break changing since the underlying libraries have jumped significantly in version.

Updated to NixOS 25.05 (MfGames Writing Setup Flake)

2025-01-11T06:00:00Z

We've updated the flake to be based off NixOS 25.05 and the latest version of mfgames-project-setup-flake.

Updated to NixOS 24.11 (MfGames Writing Setup Flake)

2025-01-11T06:00:00Z

An occasional chores, we've updated the flake to be based off NixOS 24.11. From our understanding, the flake input could always be changed but this sets up a nice default using the current, non-deprecated version of NixOS.

Along with this, we've also updated to the latest version of mfgames-project-setup-flake which does the same thing (and copies the same first paragraph as this post).

Update to NixOS 24.11 (MfGames Project Setup Flake)

2025-01-10T06:00:00Z

This came with a couple surprising changes, mostly in behavior from our tools. In specific, treefmt got a lot noisier with 24.11 when it came to unknown files in the repository (like .php files we we don't have set up). Modifications were made to the linked treefmt.toml file to not report those to avoid a wall of text when there were a lot of them.