4 ms·
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 (a
by jamesgeck0 4y ago
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.
- cxr 4y ago> 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.
- jamesgeck0 4y agoKeeping 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.