feat(nix): add flake to support nix builds

[emrtnn]

Closes #215

As suggested in the issue, this PR adds a flake.nix file that Nix users can use to natively install and run the package.

The way I structured it is a top-level flake.nix that imports .nix/package.nix, the file containing the actual logic for building Hunk.

This is designed so no core maintainer needs any Nix knowledge:
Inside .nix/, there is a nix-deps-hash.txt file that's generated by the new bun run nix:update-hash script. Whenever the project's dependencies change, the Nix build will temporarily fall out of sync until someone runs this script to fetch the new hash. I suggest automating this via CI in the future so it's entirely hands-off for you, but I didn't want to make this initial PR too broad.

Since @MarkusZoppelt has already opened a PR (NixOS/nixpkgs#517626) to officially add Hunk to nixpkgs, this flake can be used by the community in the present while we wait for that to merge. Later, it will remain highly useful for local development (nix develop) and building purposes directly from source (the local building strategy is different from how nixpkgs will fetch the binary). I also used the exact same package name he chose, as discussed in his PR.

[greptile-apps]

Greptile Summary

This PR adds Nix flake support so users can install and run Hunk natively via Nix, without requiring any Nix knowledge from core maintainers. The design uses a two-phase build — a fixed-output derivation to fetch and hash-verify node_modules, then a standard derivation that compiles the binary — with a helper script to regenerate the hash when dependencies change.

• flake.nix / .nix/package.nix: Introduces a well-structured flake exposing per-system packages.default and devShells.default, delegating actual build logic to .nix/package.nix. The meta.platforms field claims support for all platforms, but Bun is only available on four targets; builds on other architectures will fail at evaluation time.
• scripts/update-nix-hash.sh: Provides the bun run nix:update-hash workflow for refreshing the FOD hash after dependency changes. The grep -oP invocation uses a Perl regex flag not supported by macOS BSD grep, so the script will always fail for Mac-based maintainers without GNU grep installed.
• .gitignore / flake.lock / .nix/nix-deps-hash.txt: Supporting files are all correct — the result symlink is properly ignored, the lock file pins a specific nixpkgs revision, and the initial hash is present.

Confidence Score: 3/5

Safe to merge for Linux users, but two defects affect Mac maintainers and non-x86/ARM builders before they can be fixed post-merge.

The platforms = platforms.all declaration lets Nix attempt to build on architectures where Bun has no binary (RISC-V, s390x, i686, ARMv7, etc.), which will fail at build time rather than showing a clean unsupported platform message. More immediately impactful, the grep -oP call in update-nix-hash.sh is dead on any Mac using the system BSD grep — NEW_HASH will always be empty and the script exits with an error, making the hash-update workflow completely broken for Mac-based contributors.

.nix/package.nix (platforms list) and scripts/update-nix-hash.sh (grep portability) both need small fixes before the maintainer workflow is fully functional on macOS.

Important Files Changed

Filename	Overview
.nix/package.nix	Defines the Nix derivation using a two-phase FOD approach (deps + build); platforms = platforms.all incorrectly claims Bun supports every architecture.
scripts/update-nix-hash.sh	Hash-update helper that intentionally triggers a failed build to extract the correct FOD hash; uses grep -oP which breaks on macOS's BSD grep.
flake.nix	Adds a valid flake exposing packages and devShells per-system; delegates package definition to .nix/package.nix.
flake.lock	Auto-generated lock file pinning nixos-unstable and nix-systems/default; looks correct.
.nix/nix-deps-hash.txt	Stores the sha256 hash for the fixed-output node_modules derivation; content is valid.
package.json	Adds nix:update-hash script pointing to the new shell helper; change is minimal and correct.
.gitignore	Adds result to gitignore, which is the symlink Nix creates in the CWD after a build; correct addition.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[flake.nix] --> B[import .nix/package.nix]
    B --> C{bunDeps FOD}
    C -->|Network enabled| D[bun install --frozen-lockfile --ignore-scripts]
    D --> E[node_modules verified by sha256 hash]
    E --> F[Main derivation - no network]
    F --> G[cp node_modules from bunDeps]
    G --> H[bun run build:bin]
    H --> I[dist/hunk binary]
    I --> J[$out/bin/hunk installed]

    K[nix:update-hash script] -->|Writes dummy hash| C
    C -->|Build fails - hash mismatch| L[Extract correct hash from error output]
    L -->|Write to| M[.nix/nix-deps-hash.txt]
    M --> C

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
.nix/package.nix:63
Bun's binary is only available for `x86_64-linux`, `aarch64-linux`, `x86_64-darwin`, and `aarch64-darwin`. Using `platforms.all` will let users attempt to build on i686-linux, armv7l-linux, riscv64-linux, s390x-linux, and others where `pkgs.bun` itself is unavailable — the build will fail with a confusing "attribute missing" error rather than a helpful "unsupported platform" message. Restricting `platforms` to Bun's actual supported set surfaces the issue clearly before the build starts.

```suggestion
      platforms = [ "x86_64-linux" "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
```

### Issue 2 of 2
scripts/update-nix-hash.sh:9
The `-P` (Perl-compatible regex) flag is not available in macOS's BSD `grep`. On any Mac the command silently produces no output, `NEW_HASH` stays empty, and the script exits with the "❌ Failed to extract hash" error. The `\K` keep-assertion can be replaced with `-E` (extended regex) plus a `sed` strip, which works on both GNU and BSD toolchains.

```suggestion
NEW_HASH=$(echo "$OUTPUT" | grep -oE 'got:[[:space:]]+sha256-[a-zA-Z0-9+/=]+' | sed 's/got:[[:space:]]*//')
```

_{Reviews (1): Last reviewed commit: "feat(nix): add flake to support nix buil..." | Re-trigger Greptile}

[m4r1vs]

Hey, I just opened basically the same PR, only using bun2nix instead of your impure network-enabled solution. I've had very good experience with bun2nix in the past. I think it would be a little annoying having to update the hash every time a package is updated -- especially by people who don't use nix.

I can see that having the bun.lock.nix file which bun2nix requires could also be confusing for people not using nix. Also the added postinstall script.

If this PR is the way forward, I'd suggest adding your bash script to postinstall such that the bunDeps hash is automatically updated. Otherwise it looks good to me.

[m4r1vs]

Also nodejs is not needed in the devShell I think -- even though it's listed as a requirement in CONTRIBUTING.md. Not sure why it is. Git should always be installed but could be added to the devShell as to be explicit.

[emrtnn]

Hey, thanks for the comment! Yeah indeed I tried yesterday to build it using bun2nix but adding the postinstall script gave me a lot of issues because this repo uses bun as a dependency itself so it was causing a conflict between the nix installed bun and the repo installed bun by the nix one. Since I couldn't manage solve this I chose this way.

Didn't know you were also working on this if I had I wouldn't have made this PR, that's why I opened #215 before anything.

That said, if you agree with following with this PR I consider your postinstall suggestion a really good catch and will be happy to add it. The only issue I see is that it will make installing deps much slower but maybe that's not that big of a deal for core contributors

[m4r1vs]

I think it's very cool how we took two different routes and both landed at a valid solution to the problem! I too ran into the issue with the bun dependency in package.json. However, I just removed it there xd

[m4r1vs]

I think the hash might change across architectures (darwin/linux and x86/arm64). I can test this if needed

[emrtnn]

Removing it was also my first thought but I want to believe is there for an unknown reason to us and I usually try touching core files like package.json as little as possible.

Now that you speak about that I think you are right too. I can also test tomorrow at work where my machine has an ARM CPU. If our concerns are right then I don't think this is anymore a viable method. We would have to add a json file with one hash per architecture instead of a txt one and that is a maintenance nightmare.

We should use bun2nix if that happens but I just want to be sure that there's no issue with deleting bun as a dependency in package.json so this PR can be closed in favor of yours.

Any core maintainer can give opinion on removing it?

[m4r1vs]

just tried it on arm64 fedora and indeed the hash is different :/

[emrtnn]

Closing this PR after the node_modules hash discovery. As @elucid said we should focus on #231 and find a way to workaround the node_module's bun issue without removing it. Thanks to all for your time and feedback!