My strategy for dealing with bit-rotting builds is to use yarn with plug-n-play. It goes farther than creating a lockfile by saving a zip of every dependency (and yarn itself) in a directory that you check into your repo. Combined with a Node version file, you can be pretty sure that you’ll be executing the exact same code in a decade.
The trade off is that because it’s actually reading JS from the zip files at runtime, a lot of Node packages don’t play nicely with it. Once you get things set up, it’s great, but getting there can be exhausting for a hobby project.
> plug-n-play [...] goes farther than creating a lockfile by saving a zip of every dependency (and yarn itself) in a directory that you check into your repo
Imagine that: using your VCS/SCM to version control the code that goes into making your app work.
> Combined with a Node version file, you can be pretty sure that you’ll be executing the exact same code in a decade.
I have news for you: the Yarn-/NodeJS-specific stuff isn't necessary. With the code in your repo, you're able to roll back to a specific revision at any time. That's the whole point of version control.
Keeping a note of which version of NodeJS the project was originally developed with is absolutely necessary; it periodically makes breaking changes in major releases. I literally just had to debug a project where the build was failing due to a Node version difference.
And you _can_ manage a dependency tree and keep everything up to date by hand, but it's much nicer to let Yarn do it for you.
The trade off is that because it’s actually reading JS from the zip files at runtime, a lot of Node packages don’t play nicely with it. Once you get things set up, it’s great, but getting there can be exhausting for a hobby project.