Game devs commit their dependencies. Maybe we should too. &larr; nathanflurry.com<br>Game devs commit their dependencies. Maybe we should too. March 29th, 2026 — summarize with Claude | ChatGPT<br>I spent 6 years in the gaming industry before starting rivet, an open-source project for orchestrating stateful workloads. The way people are using our software is starting to look a lot like how game developers build software.<br>But npm is getting in the way.<br>Game devs commit their dependencies<br>Game devs don't use package managers in the same way npm works. Their dependency system looks a lot different than what you think of as a package manager.<br>When you install a package for a game, you literally copy the entire package into your repository and commit it to git. The expectation is that you are going to modify your dependency directly .<br>The exact process varies a bit per each engine:<br>Unreal plugins are vendored source in Plugins/, engine itself is commonly forked from Epic's GitHub<br>Unity asset store copies source into Assets/, UPM supports local/git packages you can modify<br>Godot asset library downloads plugins into addons/, they become regular project files you commit and modify freely<br>other engines vary from engine to engine, but the general practice is the same industry wide<br>This package management approach stems primarily from the need to customize everything on a per-title basis . These customizations usually stem from:<br>customized rendering pipelines<br>specialized netcode<br>specialized physics engine behavior<br>fine-tuning performance<br>specialized platform support (consider yourself grateful for never having to ship a PlayStation/Xbox/Nintendo title)<br>Games have less dependencies<br>But there's one important caveat to why this works: games have very few dependencies .<br>the engine itself (yes, the engine gets forked too)<br>physics engine (often part of the engine)<br>vfx<br>netcode<br>artist pipelines<br>You're not going to find left-pad on the Unreal asset store.<br>Why AI is making all software more like games<br>In 2023, forking dependencies regularly would've sounded bizarre and unmaintainable.<br>However, there's 3 big shifts happening in AI-assisted software development:<br>#1: No more tiny libraries<br>Tiny libraries used to be all the rage on npm. Now AI can oneshot them perfectly.<br>Our codebases are starting to look a lot like games where engineers prefer to rewrite tiny tools in-house from scratch.<br>Our dependency list is getting smaller, but...<br>#2: Frameworks are becoming even more important<br>LLMs need structure to work around. Frameworks provide that rigid structure.<br>As our dependency list starts getting whittled down, the framework (e.g. Nextjs, AI SDK, Supabase, our work on Rivet actors, etc) starts looking like the "game engine" for your software.<br>Think of how a game engine lets a team produce thousands of entities for something like GTA V. Frameworks do the same thing for AI-generated code : they provide the structure to scale reliably.<br>#3: Forking/patching is sooo easy<br>You no longer need to understand a codebase to fork or patch it. LLMs have made this a non-issue.<br>Much like game engines that need to fork for customization, AI has made this a reality for the rest of the industry.<br>How we see this at Rivet<br>We're watching this happen in real time at rivet. Customers are forking our libraries, patching internals for their specific infra, and sending us the changes upstream.<br>But npm makes this painful. Monkeypatching, version lock conflicts, no clean way to vendor a fork. It's fighting the toolchain every step of the way. We rely heavily on pkg.pr.new for being able to ship changes quickly from git commits, but it's a partial fix to a more complicated problem.<br>If dependencies were managed more like game engine plugins (vendored, forkable, expected to be modified) this would be much simpler.<br>And this isn't unique to Rivet. Any framework that becomes "the engine" for your codebase is going to hit this.<br>On the future of software development<br>Game engines tend to have specialized tools for managing dependencies in this pattern & usually have complex build pipelines to support this.<br>It's possible to use git submodules or git subtrees today with npm, but there are quirks with build pipelines, collaboration, etc. that still need to be worked out.<br>Maybe someone will replace npm with something that operates on submodules/subtrees instead of a node_modules folder. Tbd, it deserves more thought.<br>tweet at me if you have thoughts/are adopting a similar pattern, I'm very interested to see where this is going.

Share

If you enjoyed, please consider sharing: Hacker News | Lobsters | X | Reddit

Author

I'm Nathan. I spend my days working on Rivet, a modern actor runtime. My DMs are always open on X.

&copy; 2026 Nathan Flurry

nathanflurry.com June 2026 NATHANFLURRY.COM(1)