alyxia.dev

A Retrospective, Ex Post Facto

Sun, 31 Dec 2023 00:00:00 GMT

Today marks the final day. We’ve all seen a whole lot this year, no?

Ups and downs plenty, but I’m alive. I’m working on myself, and it’s going better than ever. I’m happy.

So, let’s go over a couple of things I’ve done this year.

Joining Brik.digital

This year marks the year I started my first actual job. It was masked as an internship for school, which all in all it really wasn’t. Besides the reports and assignments I had to do about my work for school, to me this was nothing like the average internship.

I wasn’t treated like an intern. I was treated like a coworker. Someone who’d been there for years. I don’t think I’ve ever integrated into a team this quick. I found my place so incredibly fast between these wonderful people, and I’m eternally grateful for being given the opportunity to stick around for as long as I did.

It was supposed to be an internship that lasted half a year, from February 2nd to June 26th, however, I was offered a temporary contract throughout the summer holiday if I was interested in that. Being willing to continue growing in this team, I accepted without hesitation. I only had two weeks of summer holiday this year compared to the usual six. But it was worth it!

I learnt a lot, was able to work on ton of cool projects, and it didn’t stop there. My education was supposed to last four years, but I was told I was able to skip a year if that fit my needs more, as the third year was full of stuff I’d likely already know. So I did. And then another big switch-up happened; they moved the internship period of the fourth year from the second half to the first half of the year. Meaning that starting the 28th of August, I’d be right back in the office until the 2nd of February 2024.

There’s only plus-minus one month left until that day. And that only really strikes in now. Each of the people there have been the kindest, most wonderful people I’ve had the pleasure of working with in a very long time. I’ve worked on some amazing things (some of which even publicly available!), went on a couple outings with them, helped move to the new office, and so much more. I’ve taught my coworkers new things, they’ve taught me new things, and honestly I could keep going about everything I’ve accomplished there this year.

It’s been a great time, for any of you folks there that end up reading this. Thank you so much.

CrossCode Modding

This, like many others, is also a year in which I spent a lot of time doing more work for the community that I originally started out in; the modding community for the brilliant video game CrossCode. (it’s on sale until January 4th! go buy it!)

Here’s a list of personal projects I worked on this year, in order of how cool I think they are:

CCProjectRed: Story expansion set in a certain game area (currently private as per request from one of the team members)
cc-touchbar: Mod with a native Node module for controlling the MacBook’s touchbar
CCHijack: Injects into the game before it even loads, allowing you to write your own game
cc-quickinfo-exp: Simple mod for showing the EXP an enemy will give you in the quick info dialog
cc-alybox: Library mod containing game tweaks and features for other modders
CCPostDLC: Allows you to continue playing the game after the DLC ends
CCOldMedia: Brings back a couple old assets and audio tracks from v0.7.0

Aside from these personal projects, I obviously also contributed to a couple projects on the organization, CCDirectLink:

CCLoader3: Next generation never-to-be-released modloader
ccbot: Central community bot; worked on a huge codebase refresh/update
ultimate-crosscode-typedefs: Huge conglomerate repository with type definitions for the game
c2dl-web: c2dl.info website written in Laravel
cc-ts-template: Simple TypeScript template for your new mod

I’d like to thank 2767mr, Emi, Nax, EL, krypek, and image not found for being such nice and clever people to interact with.

Discord Modding

And of course, just like the past three years, I’ve contributed and done lots of stuff for various Discord mods.

There’s too many people to thank in this community, so I’ll just skip over that for now. Thank you all :)

Replugged

replugged-web-rewrite: Complete rewrite of Replugged’s front- and backend in Laravel
installer: Replugged installer written in Go using Frenyard
replugged: Replugged itself, of course
replugged-plugins: My Replugged plugins repo

moonlight

moonlight-extensions: My moonlight extensions repo

Personal projects

Lastly, let’s go over some personal projects I’ve done this year. Despite there not being a lot of those, there’s quite a couple things I did for them!

dotfiles: Lots of stuff in lots of different places here.
- Good couple plugins for hh3
- Started using Nix
- Worked on the Neovim config where necessary, along with an attempt to write a new config
- Did some script/zsh config maintenance
alyxia.dev
- Rewrote my old website in Common Lisp starting Dec 30th 2022
- Did a bunch of work over the course of this year, both functionality and UI wise
- Got in touch with Mihai Bazon, the creator of the web framework I used
- Currently working on a rewrite in ReScript!

Advent of Code

This year I also hosted my annual Advent of Code leaderboard, bringing out some of the people I thought were totally gonna dig a challenge like this.

Thank you to all participants:

Tasky
Niels
birb
image not found
krypek
EastArctica
Chris
Maru
Nax
Nico
Janneke
Snare

As I said to you all already, I hope to see you December 2024 for the next round :)

…and that just about rounds this year up. It’s been a rough one, but we’re all still here, aren’t we?

I’d like to extend my additional thank you to some people who I’ve only really interacted with through DMs this year. You know who you are.

Happy New Year, hopefully 2024 is going to be a good year for y’all.

Cheers!

2024 in Review

Tue, 31 Dec 2024 00:00:00 GMT

Today marks the last day of 2024. It was quite the turbulent year, but for me it’s been quite a positive one. Which I’m glad I’m able to say, given how the past couple of years haven’t exactly been favourable.

I’ve accomplished a lot this year, and I’d like to go over a couple of them.

Events

I graduated from school.
I turned 19.

Personal projects

alyxia.dev

Late 2023, I redid my website’s design and internals using ReScript after a failed attempt where I used Common Lisp with Sytes.

Unfortunately both of these attempts failed due to one deciding factor: I didn’t work with the languages often enough to remember how to use them. I don’t update my website every week, not even every month. The most I might do is add some people’s 88x31 badges to my friends page. This obviously meant that I barely touched the code part of the project, and as a result I barely remembered how to do some things after a while of not working on it.

Not long after making this realisation, I decided it was time to say goodbye to ReScript and move to something I actually knew how to maintain in the long run. So, I took the design with me and moved to Astro. I decided to use Vue for the majority of the frontend components because it was handy for fetching dynamic data like my Last.fm songs & my status.cafe status.

AlyCMS

Somewhere near the start of 2024, I did some final feature implementations and bugfixes to my own content management system, AlyCMS, and left the project there. It’ll take a lot more time for this tool to become viable and potentially function as the actual content source for this blog, but it’s time I either don’t have or am not willing to spend working on it.

However, due to the rising attention of social network Bluesky’s protocol ATProto, I figured I’d try my hand at implementing authentication and data storing using it. I inevitably got stuck and put my work on this branch, which I intend to finish sometime in the future.

Misc

Besides all that, here’s a loosely date-sorted list of stuff I’ve done.

Overhauled the project structure of CCLoader3
Tried to write a modloader for a game about coffins
Wrote a version archiving toolchain for a game about coffins
Made some fixes to Frenyard
Wrote a Raycast extension
Wrote a somewhat functional music bot
Wrote a Spicetify plugin to control media playback with my macropad
Wrote a couple Coder templates
Together with friends, started a modloader for a rhythm game
Wrote a converter for osu!mania charts to said rhythm game
Wrote a couple ULTRAKILL mods in F#
Started working on a website for a local scouts group
Tasky and I made a somewhat successful attempt at obtaining Mintlify’s source code and using it to build a static docs site
Wrote a script to mirror an entire GitLab organisation to GitHub

Brik.digital

Like last year, I’d like to take a moment to look back on the various projects I’ve worked on for my job this year. It’s been a rather turbulent year and personally I believe I’ve made some crucial contributions to the very way we work in our development team. Aside from that, I’ve managed to even publicise some of the work.

Project Baseplate

Most notably, this year I spearheaded the development of our project template. The one we used before was originally made for Craft 3, using now outdated standards and toolchains, which we upgraded along the way as we saw fit. It currently does use Craft 5, but it still employs a bunch of outdated and suboptimal strategies, because the way the template does things was never changed. New things were just tacked on.

So, after a couple of internal discussions to figure out what we needed/wanted, I was given the green light to start working on a new template from scratch. I started out by bumping any dependencies we wanted to carry over to their latest versions, and got to work. My first order of business; come up with a better system for our JavaScript.

I made the decision to ditch our old JS code (which in most projects always ended up being stuffed into the main app.js file) and replace it with a neat TS based dynamic importing system. It works as follows:

import ComponentLoader, { Component } from "./loader";

const componentLoader = new ComponentLoader();
const components: Component[] = [
  {
    name: "alpine",
    selector: "[data-alpine]",
  },
];

for (let component of components) {
  componentLoader.loadComponent(
    component.name,
    component.selector,
    component.plugins ?? []
  );
}

This will dynamically load the components/alpine.ts file when an element with the data-alpine attribute exists on the page. Said file exports a default function which will then get executed. It allows us to lower the amount of code loaded and executed when certain elements aren’t even present on the page. Very neat, and very clean.

Another big thing I introduced was the use of Storybook, which wasn’t just something new for our team, but is something I pioneered in the public Craft CMS community. There are old projects on GitHub that demonstrate the use of Storybook in a Craft CMS environment, but they were terrible hacks. One of them even rendered the Twig templates client-side by using a JS implementation of Twig. A 2021 talk concluded that it was “terribly difficult” to integrate Storybook into Craft CMS.

After more discussing of the idea internally, I started working on an integration, and… got it functional in a single night of work. The way it works is rather simple:

We override Storybook’s fetchStoryHtml function and make a request to a custom controller with the path to the current .stories.json file along with all the selected properties/options
We fetch the corresponding .twig file on the server, construct a fake Twig template in a string in which we place the contents of our component’s .twig file, and render it
We send the resulting HTML back to Storybook
We do some final post-processing of the returned HTML on Storybook’s side and send it off to the renderer

We’ve been working with Storybook since I added it, which is about two to three months ago. There were some bumps here and there which I managed to iron out pretty well, but I’ve heard nothing but positive feedback from my coworkers, so I think this was a good addition to our workflow. On top of that, we can statically build Storybook and serve it on a project’s staging domain, which we can then hand over to the design team for review. Using something like Marker.io within Storybook allows us to have a very fluent workflow from design, implementation, and feedback.

composer-patches-regex

The problem

Internally, we sometimes use composer-patches, a project much like pnpm’s builtin patching functionality, to apply changes to dependencies before installing them. It, much like pnpm’s functionality, has one fatal flaw: it relies on diff files. It might not sound like a big deal, because you can just pin the dependency version and ensure the patch always applies, but for a fast-moving project like Craft that releases a new version every week, this isn’t exactly ideal, because there’s a small catch when using diff files for patches.

For those unaware, here’s a sample excerpt from a patch:

diff --git a/src/elements/Asset.php b/src/elements/Asset.php
index acde040fb2..568475202e 100644
--- a/src/elements/Asset.php
+++ b/src/elements/Asset.php
@@ -276,7 +276,7 @@ class Asset extends Element
      */
     public static function isLocalized(): bool
     {
-        return true;
+        return false;
     }

     /**

What this basically says is “on line 276, replace what is prepended with a - with what is prepended with a +”

If you haven’t figured out the problem with this at first glance, let me once again point you to the fact that it relies on line numbers to tell the patch applier where the changes are. So what happens if code is inserted above the lines I’m patching? The line numbers for the lines I’m patching increase, of course, meaning that my patch now no longer applies.

My solution to this was simple. And it all comes back to Discord client modding. A couple well known projects use something we call “plaintext patching” to change Discord’s code. The way code is patched, in essence, is like this:

// Original content
const calculateSum = (a, b) => a + b;

// Patch
const patch = {
  find: /a + (b)/,
  replace: (_, b) => `a + 10 + ${b}`,
};

// Changed content
const calculateSum = (a, b) => a + 10 + b;

We can make clever use of Regex capturing groups to carry over or reference original pieces of code in our replacements, or get rid of code entirely if we so desire. So I figured… why not take the same approach for Composer dependencies?

The solution

To remedy my gripes with the way composer-patches works, I built composer-patches-regex, an extension upon the original package to allow for regex replacements in dependencies. A patch for composer-patches-regex looks like this:

{
  "patches": {
    "scope/packagename": [
      {
        "files": {
          "someFile": [
            {
              "find": "/some/",
              "replace": "a bit of"
            },
            {
              "find": "/original/g",
              "replace": "copied"
            }
          ]
        }
      }
    ]
  }
}

A couple fields required to make this all word were omitted for brevity, but it’s enough to show off the gist of what we’re doing here. We specify a file using the key in the files object, and specify the patches to execute on this file. Similarly to the JS based approach, we can leverage capture groups and specify them in our replacements using $1, $2, andsoforth. The numbers are ordered in the appearance of the capture groups.

Sure, this solution isn’t entirely waterproof, but it sure will hold up a lot longer than diff files, as we now no longer depend on the position of the code, but instead the structure of it, which is obviously much less likely to change.

Statuspaginator

Statuspaginator was a project I started building in late 2023 and having received mostly neglect since then, its main purpose being giving us a clear overview of the different Craft CMS sites we were running and which versions they were on. This would be especially useful in the rare case a security vulnerability was found in Craft, and was the main reasoning behind the project’s development.

Fast forward to December 18 2024, on a peaceful evening, at 8PM… GHSA-2p6p-9rc9-62j9 was published. A critical RCE vulnerability was found. At that very moment, Statuspaginator finally demonstrated its usefulness, as every affected site now lit up red:

For the sites that were being tracked by Statuspaginator (which is frankly a fraction of the projects we run) we could easily see which projects were affected and which weren’t. Despite the circumstances, I felt a sense of pride knowing the thing I built actually did its job pretty well.

marker-to-youtrack

Sometime in August we were figuring out if we wanted to migrate from Jira to JetBrains YouTrack. Jira is expensive, especially so since we’re paying for a lot of functionality we barely use. After a whole lot of research, we found there was only a single blocking issue keeping us from migrating: integration with Marker.io. Marker is a crucial part of how we let our clients submit feedback to our Jira service desk, which is made particularly easy through Marker’s builtin integration with Jira. This wasn’t something we were willing to lose, so I took matters into my own hands and built marker-to-youtrack.

There was just one issue… Marker doesn’t have a public API. There has been an open feature request since late 2022, but despite the attention given to it, nothing’s been done with it so far. My solution? Puppeteer. The process is simple:

Start a Puppeteer instance and navigate to Marker’s signin page
Input the email and password
Wait for Marker’s dashboard to load
Fetch the browser’s cookies and extract the markersess cookie

Now I could monitor the devtools’ network tab and see what requests Marker made to its own API to fetch data. I figured out what request was made to obtain a full list of projects, and at that point I could configure a webhook on a Marker project to send events to marker-to-youtrack’s URL. I got whatever data I needed from the project through the webhook event (for example, a new Marker issue), fetched any additional project data from the previously obtained list of Marker projects, and created a corresponding ticket in YouTrack.

In essence, a very simple tool, but it was a nice challenge regardless!

Craft plugins

Aside from all of the above, I’ve also brought new life to our GitHub organisation by publicising a good chunk of the work I’ve been doing. Here’s a small overview:

Wrote TypeScript type definitions for Craft’s window globals on craftcms-typedefs
Upgraded the unmaintained Craft Readtime plugin to Craft 5
Wrote a plugin that adds a custom field type for specifying a store’s opening times
Upgraded the unmaintained Craft SCSS plugin to Craft 5
Upgraded the unmaintained Craft Cookiebot plugin to Craft 5
Published entry-navigation, a plugin to edit navigation nodes from an entry’s editing page
Published entry-type-permissions, a plugin to allow fine-grained permissions of entry type creation

Advent of Code

As per usual, I hosted my annual Advent of Code leaderboard this year. I asked the participants of last year if they wanted to participate again, and brought in some new folks too. Besides that, I started using the rather handy aockit by Tasky to support using arbitrary programing languages for my solutions instead of locking myself into TS for the auto-downloading of inputs.

Thank you to all participants, in no particular order:

image unavailable
Isabel
M6
maeve
marsh
Nax
Snare
Mopi
Anya
Basil
Janneke
Krypek
Maru
Niels
20
Tasky

This year exceeded my expectations once again, and I’m glad I’m able to host this little leaderboard for my friends every year. It brings me pure joy to see folks interact with eachother and see what solutions they come up with to the problems presented.

I hope to see you all again next year. :)

…and that just about rounds this year up. Looking back at everything, it sure was an eventful one. It took me about three days to write this all out, both because I have trouble writing long-form stuff, but also because I kept having to look back through my account histories. There’s a lot more I’ve done that I haven’t explicitly written out here, and if you’re really that interested, feel free to take a look at my GitHub.

Lastly I’d like to express my gratitude to everyone I’ve talked to this year. I’ve made a bunch of new friends and livened up my friends page as a result. Thank you all for sticking around.

Late happy new year’s to you all!

Applying hobby knowledge to work

Sat, 15 Jun 2024 00:00:00 GMT

For years now, I’ve been programming as a hobby. It’s my passion to create, even if the things I make aren’t perceived as useful. One thing I’ve noticed is that over the years, you start looking back on older projects as a reference for anything you’re currently working on.

Recently, my employer asked me to finish a plugin he was working on for the CMS we offer to clients. There’s a library in the frontend code for the CMS that the creators wrote themselves that looked strangely familiar to something I’ve worked with before.

But before I get to that, I have to explain why this was so familiar.

Classes in early JavaScript

JavaScript didn’t get any native support for classes until ES6 (which released in 2015) despite already having the new keyword which could call a function and return a new object with said function as the .prototype.constructor property.

var a = function (name) {
  this.name = name;

  this.sayName = function () {
    console.log('I am ' + this.name);
  };
};
var Class = new a('Alyxia');

Class.sayName();
// => I am Alyxia

In 2006, Dean Edwards (who I can find surprisingly little about), published Base.js, a single file you could add to your website to ease the process of creating class-like objects in JavaScript.

var object = Base.extend({
  value: 'some data',
  method: function () {
    alert('Hello World!');
  },
});
object.method();
// ==> Hello World!

This way, anything that calls extend on Base, is also inherently extendable. So in this example, object.extend(...) would be completely valid, and the resulting object would inherit any methods and properties from object.

This system worked as follows, where A is Base and C is your class definition:

Upon calling B = A.extend(C), copy all properies and methods of C into a new object
Set C’s prototype to that of A
Link the inherited methods from A into C

It sounds complex, but in practice, it’s dead simple and quite intuitive.

Simple Inheritance

In 2008, John Resig, who is best known for his work on world-renowned library jQuery, wrote an entire yet simple inheritance system in JavaScript for the in-progress book he was writing.

After seeing many attempts at “class systems” in JavaScript, two were his favourites, namely Dean Edwards’ Base.js, and something I’d never heard about before called Prototype.

Resig wrote a blog post about his attempt here if you’re interested in the way the thing looked. All in all it’s pretty similar to Base.js, except Resig’s attempt had a considerably shorter implementation for the extend function.

Impact

The majority of game engines in the modern day are written in object oriented languages. This was no different back in 2010, with well known engines like Unity and Unreal Engine being written in C++. To clearly separate concerns in your game, it’s typically recommended to use classes as well. (e.g. a base class Entity that Player and Enemy extend from)

In late 2010, Polish developer Dominic Szablewski, otherwise known as phoboslab, open sourced v1.14 of his game library Impact.

Impact, which is largely a “bring your own glue” game engine, was obviously also written before JavaScript had any coherent concept of classes. That’s why Impact’s core file directly included John Resig’s implementation of the class system. Basically every system in the game, like entities, the input manager, the sound system, collision/background maps, were all written using ig.Class.extend(...).

This meant that, for example, fonts were simple to implement. Fonts are image files. The font specific functionality is in ig.Font, which is defined as…

ig.Font = ig.Image.extends(...)

So even in Impact’s own source code, it makes use of this system to separate concerns. The handy thing about this is that game developers could do the same thing; create their own extendable classes or extensions of existing ones.

There was one core difference in comparison to Resig’s implementation that Szablewski added himself: ig.Class.inject.

Injecting into classes

What made Impact so different is its ability to inject into classes at runtime. The best way to explain is to just give an example:

ig.Person = ig.Class.extend({
  init: function (name) {
    this.name = name;
  },
  sayName: function () {
    console.log(this.name);
  },
});

var me = new ig.Person('Alyxia');
me.sayName();
// => Alyxia

ig.Person.inject({
  sayName: function () {
    console.log('Hello, my name is ' + this.name);
  },
});

me.sayName();
// => Hello, my name is Alyxia

To explain:

Create a class named Person with a method that logs out the name
Create a new instance of Person named me with name Alyxia
Call sayName, which logs out the person’s name
Inject into ig.Person to change the functionality of sayName, permanently altering all existing and future instances of Person
Call sayName again, showing our new output

Technically, if you were to build a game with Impact, your game is inherently moddable.

Speaking of…

CrossCode

CrossCode is an action RPG released in 2018, which started development in 2011.

I’ve been in love with the game since I discovered it, and as such I’ve been a part of the modding community since late 2018. After people discovered how to run their own code before/during the game… modding became extremely easy. This is because it used Impact as the game engine. 95% of the game’s core functionality is defined in Impact classes that are accessible through the global objects ig and sc.

Nowadays, a good chunk of the mods for the game are written in TypeScript. The requirement for comfortably being able to access stuff on ig and sc, and additionally call extend and inject on any classes, is writing type definitions for everything.

Community member dmitmel made great effort toward this goal during the development of the first big TypeScript mod, crosscode-ru, which is a Russian translation of the game. To properly mod the game in TS, he wrote type definitions (labeled the “Ultimate CrossCode Typedefs”, later in this post referenced as UCCTD) which eventually resulted in a single repository specifically meant for containing typedefs for the entire game.

The most important and core part of these typedefs are the definitions of Impact’s class system.

For global classes in the game, like sc.ItemListBox, we can define them like this:

declare global {
  namespace sc {
    interface ItemListBox extends ig.GuiElementBase {
      list: sc.ButtonListBox;

      clear(this: this, skip?: Nullable<boolean>): void;
      addButton(this: this, gui: ig.FocusGui): void;
      getChildren(this: this): ig.FocusGui[];
    }
    interface ItemListBoxConstructor extends ImpactClass<ItemListBox> {
      new (
        topPadding: number,
        noHeader: boolean,
        buttonInteract: ig.ButtonInteractEntry,
      ): ItemListBox;
    }
    var ItemListBox: ItemListBoxConstructor;
  }
}

Here we see a couple things:

The ItemListBox interface properly extends from ig.GuiElementBase, which is defined elsewhere in a similar fashion
All the properties in this interface will be available to instances of the class. (so after calling new on it) Third, the ItemListBoxConstructor acts as our “callable constructor” and contains the arguments we pass to the constructor.
The ItemListBox var is a reference to our constructor and is the thing that eventually appears on the sc namespace.

So, now we’ve got type definitions for sc.ItemListBox so we can call it as normal code, with type checking. Why am I highlighting this project though…?

The actual gist of the post

At work, we use CraftCMS to build websites for customers. The point is that we architecture the CMS in such a way that eventually, customers can completely self-manage their websites content-wise, so we won’t even have to intervene with over 60% of changes they want made.

Craft supports plugins. There’s many companies and organisations making these plugins, but it’s perfectly normal for a regular developer to make their own plugin for some niche feature if it doesn’t already exist. We had to do this for a couple customers, namely store owners, so they can specify their store’s opening times in a nice table and add exceptions to those specified times.

So, I was put to work. I got most of the functionality out of the way pretty easily since one of my coworkers had done the majority of the work before I got started on it, but the main problem now was rendering nicely editable tables with time selectors so people authoring one of these opening hour tables wouldn’t have to type so much manually. Additionally, it had to be possible to create a new period below an existing one so you could, for example, say that from January through March you were opened from 8am to 5pm, and from that point onwards from 9am to 4pm.

To create one of these editable tables, most plugin developers use Craft’s very own Craft.EditableTable which conveniently exists on the window. Cool!

As clueless me traveled to the Craft GitHub repository to take a look at the source code for this thing, I stumbled across something weird. The definition of the object looked like…

Craft.EditableTable = Garnish.Base.extend({
  /* ... */
});

Huh. That’s weird. What’s Garnish? I delved further and further through Craft’s AssetBundles until I found a folder labeled garnish, and looked in there. After a bit of poking through there, I found a file called Base.js, which started with…

/*!
	Base.js, version 1.1a
	Copyright 2006-2010, Dean Edwards
	License: http://www.opensource.org/licenses/mit-license.php
*/

Ah. Well, isn’t that interesting.

Now, this is all fine and dandy, but my Craft plugin’s frontend logic is using TypeScript. If only there was a solution to this problem…

The Ultimate Craft CMS Typedefs

When I saw the way Base.js classes worked, I immediately knew I could cobble something functional together by referencing UCCTD’s Impact class definitions. There was just one striking difference between Impact classes and Base.js classes: the second argument to extend. This is what allows the developer to declare static properties on a class. (.extend({ /* instance properties */}, { /* static properties */}))

Impact classes do not have this, so I couldn’t just use UCCTD’s definitions out of the box. I ended up turning to my good friend Nax who eventually figured out how to properly type this functionality. After this was done, I created the empty stub type for Garnish’s Base class, and with that, I can now write typings for Craft’s classes.

The way they’re defined is pretty much identical to what I’ve shown off for UCCTD, with two differences:

naming (ImpactClass becomes BaseClass)
two generics instead of 1 in BaseClass (BaseClass<Instance, Static>)

And that’s how I applied knowledge I garnered from hobby projects over the years to something I actually need to do in my work. The overlap is just a small coincidence, but it’s still really cool to me.

Honestly, for one of my first long-form posts, this is awful. Way too much talking for a point I could’ve explained in a <=100 word post on some social media. This post also took me several months to finish due to how unmotivated I was to write it. Let it be known that posts like this are not my forte, but I just wanted to write about something. Hope it turned out OK.

Making my Nix config smarter

Mon, 12 Jun 2023 00:00:00 GMT

So, today I was playing around with my Nix config again, and I thought “wouldn’t it be nice if I wouldn’t need a manual imports array on my user config?”

And so I set out to figure out what a good approach was for the situation. I remembered there was a function for listing directories, because back when I was messing around with operator overloading, I used that thing to demonstrate some code:

let
  __mul = x: y:
    if builtins.typeOf y != "lambda" then x y
    else
      z: x (y z);
in
  builtins.attrNames * builtins.readDir ./.

The operator overloading obviously isn’t that important here… but it’s still fun to show off By the way, this would provide you with a list of files in the current directory. (e.g. [ ".git" "Documents" "Downloads" ])

So, with that knowledge, I set out to figure out how I could generate a list of files that the imports property could read. After a short while, I found a Reddit comment that demonstrated usage of the map function accompanied by our previous findings, attrNames and readDir. In Nix, map works similarly as in JS, as in that the following Nix code:

map (e: "test ${e}") [1 2 3]

…would give output similar to this JS code:

["a", "b", "c"].map((e) => `test ${e}`);

The code this Reddit user gave would read the current dir, which would give output like { "test.nix" = "regular"; }, run attrNames on that, which outputs a list of key names in the object, e.g. [ "test.nix" ], and then stick the path to the current derivation in front of it, like so: /nix/store/<id>-alymac/test.nix.

This works fine! There are no issues with this approach! Except for one. What if I want subdirectories? Well, you can’t. readDir gives you all files in the current directory, no more no less. After a bit of snooping in nixpkgs’ lib folder, I found just the function I need, listFilesRecursive.

After only a couple invocations of this function in the REPL, I came to the solution on how to use it. I could get rid of the call to attrNames, as listFilesRecursive outputs a list of full paths to files, not an object. With this knowledge, I edited my invocation as follows:

map (n: "${n}") (lib.filesystem.listFilesRecursive ./.)

One caveat I found with this approach was that because listFilesRecursive outputs a list of full paths instead of just filenames, I was no longer able to pop the path to the current derivation in front of n, because instead of n being a simple filename, it was now… a /nix/store path to that file. As in, /nix/store/<id>-test.nix. That’s what I get for using full paths. I guess what I could do is take the full path to the current file and trim off the irrelevant part, but it seems like more effort than it’s worth, because now you’d have to take subdirectories into account again.

And with that, my result code is as follows:

{
  importMap = map
    (n: "${n}")
    (lib.filesystem.listFilesRecursive ./.);

  importsFiltered =
    builtins.filter
      (x: !lib.strings.hasInfix "default" x)
      importMap;
}

It’s not anything remarkable in any way, but this did take me about an hour to accomplish.

Code that got me to write this post (the post content is basically just my code comment but longer)

let
  # We've got a small issue here. I tested this in a repl, and what I've
  # observed is that listFilesRecursive spits out [ /full/path/to/default.nix ],
  # while builtins.readDir spits out { "default.nix" = "regular"; }
  # In theory, this shouldn't be much of an issue, however, when using readDir
  # I would be able to do `map (n: "${./.}/${n}"), while when using
  # listFilesRecursive I have to use `map (n: "${n}").
  # The difference here is that when using listFilesRecursive, `n` becomes
  # `/nix/store/<ID>-default.nix`, meaning it can be used as-is, but when using
  # `readDir` it becomes `default.nix`, meaning the string used in the map
  # callback must be `"${./.}/${n}"` to get a path to the current derivation
  # where the nix file lives in.
  # Currently, I am unsure of the implications of having all files separately.
  # To do it "the right way" I'd obviously prefer the nix files to be children
  # of the alymac derivation, but it seems that if I want my map of imports to
  # be generated from the entire directory listing, it isn't going to work out.
  # The solution was slightly modified from this Reddit answer:
  # <https://www.reddit.com/r/NixOS/comments/j5pa9o/comment/g81dvop/>
  # So, let's get all files in the current directory...
  importMap = map
    (n: "${n}")
    (lib.filesystem.listFilesRecursive ./.);
  # importMap = map
  #   (n: "${./.}/${n}")
  #   (builtins.attrNames (builtins.readDir ./.));

  # And filter out default.nix
  importsFiltered =
    builtins.filter
      (x: !lib.strings.hasInfix "default" x)
      importMap;

in
{
home-manager = {
users.alyxia = { ... }: { # Defined further above, a list of files to import.
imports = importsFiltered;
};
};
}