Make buildable on nixos

[chrisheib]

Thanks for the awesome project! I was really struggling with setting up mo2 or vortex on linux, but this worked flawlessly.
I made some changes to get this to build on nixos, but I think they are not interfering with other operating systems, so I wanted to contribute my work on this.

My nixos dev flow is based on direnv and nix-direnv. When entering the projectfolder via terminal, nix-direnv is called via the .envrc and the shell.nix is evaluated, dependencies are grabbed and set up, and npm run start should succeed straight away.w

I'll draft a nix derivation to publish the mod loader to nixpkgs so its available to install via nix and on nixos if that's alright with you.

[lVlyke]

Hi, thanks for the PR and glad to hear you’re finding the project useful!

My nixos dev flow is based on direnv and nix-direnv. When entering the projectfolder via terminal, nix-direnv is called via the .envrc and the shell.nix is evaluated, dependencies are grabbed and set up, and npm run start should succeed straight away.w

I have a few questions as someone who has no prior experience with Nix:

1. You mentioned building/publishing the project downstream to a Nix package repository. If I’m understanding correctly, this PR is more focused on making the development environment easier to set up for Nix users. Is that correct?

2. After doing a bit of cursory research, I’ve noticed it is common in many projects to use a flake.nix file or “Flake”, which appears to be of a slightly different format than the shell.nix file you have provided. What is the difference between shell.nix and flake.nix? Are there any pros/cons of either format to be aware of?

3. Given that the configuration requires defining the versions of some dependencies, i.e. Node and Electron, it's going to have to be updated as the project is updated. My concern is that even if it works today, it will likely stop working at some point in the future. I am not able to maintain the configuration myself as I'm not a Nix user and lack the required expertise, so I would leave it to you and other Nix users to ensure that this continues to work in the future. Is this something you think you would be able to help maintain as the project evolves?

I'll draft a nix derivation to publish the mod loader to nixpkgs so its available to install via nix and on nixos if that's alright with you.

Yes, that's fine with me.

[chrisheib]

Thanks for the feedback!

1. Correct. The derivation (a script with build instructions) that gets drafted into NixPkgs will be similar in some ways to the shell.nix, but also contain the build and packaging instructions for this project and some more nix boilerplate.

2. Yes, flakes and 'conventional' nix are a bit of a ideology faceoff. Conventional nix (like this shell.nix) doesn't store the source from which to build from. When using the nix package manager you set up channels on your machine which are basically a timestamp of the nixpkgs repository. You can have multiple channels pointing to different commits in nixpkgs, and decide yourself which one to use to build the nix-shell. This makes the dependency version management a bit the concern of the consumer of the shell, but in most cases nixpkgs is stable enough that a shell from now will still be buildable in a few months with then updated dependencies. This also promotes warnings (like deprecated electron versions not being buildable anymore) in the future.
   Flakes on the other explicitly hand specify the used dependency versions. You include the actual git link ( nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";) in the flake.nix, and include a flake.lock file which specifies the commit hashes that are referenced at time of building. The shell will then be built with that specific set of dependency versions 'forever', until someone explicitly runs a nix flake update.
   Flakes are more explicit, but require some more overhead to work correctly.
   There is also a bit of a difference between dev-flakes and app-flakes. App flakes (which contain the dependencies as well as build and packing instructions for this project) are similar to the derivations that are merged into nixpkgs: Users can include an app-flake from this repo into their nix-profile (or nixos-config) and use the app without it being included in nix-pkgs. This is technically also possible with conventional derivations, but a bit more of a headache and less common. One could set up both for a project (or any combnination of conventional devshell, conventional derivation, dev-flake, app-flake). Usually it's fine to have the upstream derivation, and some kind of dev shell in the project, so that both devs and users are good to go.
   As to which one of these is better: Both are fine and nix people know how to use both. Maybe someday one of them will 'win' and dominate the other. Currently it looks a bit like flakes might become the future, but it's far from finally decided. Maybe there will be a third variant at some point that solves more of the pain points of each approach and gets better adoption.

3. Sure, I would be happy to help maintain the shell and derivation! Usually updates in the nix ecosystem are like this: Once published to nipkgs, a bot continually checks the versions of the projects git releases. When a new release is found, the bot messages the maintainers, which would be me in this case. I would then need to update the explicit version and git hash in the upstream nixpkgs derivation file and test the rebuild with the new project state. Usually in that step dependency problems are fixed. I can then also update the dev shell.

[lVlyke]

It would be better to use the latest Node LTS release (24) if possible.

[lVlyke]

Appreciate your insight, thank you for the thorough explanations! I’m fine with moving forward with this, just have a minor nit that I’ve added to the review above.

[chrisheib]

I improved the nix shell a bit, turns out I can leave out most of the dependencies. Copied them from another project, but that is apparently more complex in its setup.

Updating to node 24 worked fine, just a few additions to the package lock.

I also added a small section on nix-direnv to the development section of the readme.

[lVlyke]

Everything looks good to me. Thanks again for the contribution!