Ask HN: Post leftpad-ocolypse, practical guidelines for Node devs?

[jonahx]

[beachstartup]

"if a repo is worth using, it's worth mirroring, and archiving. and potentially forking, too."

-- i just made that up.

(but we actually do, in fact, do all of that for our major dependencies like upstream OS's, build deps, gitgub repos, cm, etc.)

if you don't have anyone on your team that knows how ......... well, you should probaby fix that.

[gonyea]

Commit your node_modules to source control. I've saved myself repeatedly by not putting node_modules in the project's gitignore.

- All developers on a project are in sync. - You can get the repo back into a good state if npm choked. - You can go back in time to a prior version with all of it's actual dependencies at that point in time.

[borplk → gonyea]

I'd suggest people bake in an archival process during their deploys so you always have a zip/tarball of the entire source code and node_modules that you deploy, but still use npm install during development.

[dizzy3gg]

Just read a few good tips here[1]. Basically shrinkwrap and use a private npm server/cache.

1 - https://news.ycombinator.com/item?id=11354147

[plugnburn]

The advice is simple: Don't rely on third-party stuff you can implement yourself with no significant effort. And for stuff you can't, backup those modules.

[jonahx → plugnburn]

What is the best way to backup modules? Do you need to create your own private module host, as you can for ruby gems?

[plugnburn → jonahx]

I may sound old but one can start with just backing up node_modules/ directory.

If third party modules are hosted on GitHub, you can fork them.

[Diti]

Is there a package manager out there with signed releases (GPG or something)?

[tmaly]

vendoring if such a thing is possible is the first thing that comes to mind