One thing I learned recently was that dependencies can be locked with npm shrinkwrap [1]. In the event that you don't want a deployment to be impacted by a newer version of a dependency.
npm-shrinkwrap covers one of the main strengths of checking code into source control, without actually needing to check in to version control. It locks versions down for your direct dependencies AND their dependencies, same as checking into your own repo would.
Does it protect against the hosting site going down and the project disappearing from the web? That's the main concern people have when they check library dependencies into source control.
Nope, but hosting an NPM mirror does do that, or mirroring the packages that you use in your projects if you want to skip the full mirror. So you can combine that + shrinkwrapping to get the same benefits.
Is using git submodules also frowned upon? (I'm aware that gitmodules UI is horrible but let's pretend it wasn't)
It seems natural to me to handle "lock in precise deps" on the version control level. Of course there is value in tools like npm & bower intelligently resolving deps with "soft lock in" like "~1.2.3" but it makes sense to me that I'd have to commit the resulting precise versions as a new submodules state.
- I now discovered "npm submodule" command but once checked out "npm will stubbornly refuse to update" them. Why?
- I tried to google for bower submodules and nobody seems to even voice the idea, although bower is more git-centric.
What am I missing?
P.S. I should admit that I'm biased by not wanting to give up the convenience of Github Pages for pure html/js (without any build/minify steps) — Pages supports submodules (one level deep) so I can just push. I should graduate to Heroku which can do arbitrary build on push I guess...
Still, there will always be reasons why some people DO check in deps and advise others to do so. Why not natively support submodules as the less harmful way to do that?
[1]: https://www.npmjs.org/doc/cli/npm-shrinkwrap.html