4 ms·
I’ve started thinking package management has too much trust now. Ideally, but probably unpractically, projects should check in their packages like they used to
by jonorsi 3y ago
I’ve started thinking package management has too much trust now. Ideally, but probably unpractically, projects should check in their packages like they used to under /lib or /third_party, and be much more suspicious of new package dependencies.
Basically, you would need to start accepting that you are responsible for any dependencies you choose to include. Any upstream changes you would need to evaluate and bring in or patch yourself.
Definitely an impossible task given how broad and deep modern package dependencies are, but at least you’d start feeling the insanity of having all if them in the first place :P.
- quickthrower2 3y agoIf NPM made some tweaks this might become trivial. Keep a node_modules/packagefiles with all the .zips that you commit to your source control. The expanded files can be kept out as they are now recoverable just using zip!
- firtoz 3y agoYarn does that in some modes.
- sakjur 3y agoWouldn’t the opposite be better? I’m not sure you could take advantage of the vast majority of files in the zip files being unchanged if you kept compressed archives.
- quickthrower2 3y agoNot sure what you mean but typically you don’t need to track changes of libraries to that level. At least not in the context of a repo using those libraries. I am thinking of treating them like binary .dlls.
- sakjur 3y agoSource control is really good at compressing text files as they evolve over time, but isn’t optimized to handle binary assets. Since a single-line patch changes the entire zip archive, you’d risk growing the size of the repository based on the number of patches.
- cxr 3y ago> Keep a node_modules/packagefiles with all the .zips that you commit to your source control. The expanded files can be kept out as they are now recoverable just using zip! What problem does this solve?