Why you should check-in your node dependencies

• devtools-frontend

  7 2,983 10.0 TypeScript

  The Chrome DevTools UI

  

The GitHub mirror of the Chrome DevTools repo has the node_modules folder here: https://github.com/ChromeDevTools/devtools-frontend/blob/mai...

But there is nuance (there always is...), the README file in node_modules is here: https://github.com/ChromeDevTools/devtools-frontend/blob/mai... - and it makes it clear the only NPM dependencies used by the build-system or infrastructure is meant to be checked-in. Other NPM packages should not.

----------

In conclusion: the linked blog-article is clickbait that misrepresents how the Chrome team manages their dependencies.

• cli

  72 7,995 9.6 JavaScript

  the package manager for JavaScript (by npm)

  

I honestly don't understand how people get this impression of lockfiles as being perfectly reliable. How are they not occasionally bitten by these bugs? Maybe I'm just unlucky, but I'm a little jealous of these developers who apparently are good enough managing/updating their dependencies and keeping their count low enough that they've never run into problems like this before.

Lockfile v1 literally ignores pinned versions of dependencies if the package.json specifies a fuzzy version number[0], and the advice of the npm team was, "it's fine, everyone will just bump a major version number of npm." And to this day, I still don't know what the expected behavior is, there really isn't a list anywhere about when the lockfile is and isn't supposed to be respected. So it's not really surprising to me that people distrust version pinning, and I always feel like I'm kind of living in a different world when people say that lockfiles just solve all version pinning problems.

[0]: https://github.com/npm/cli/issues/564#issuecomment-921314014

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• git-cache-tag

  2 0 0.0 Shell

I think that having rapid access to node_modules can be very helpful sometimes. The solution I came up with was this:

https://github.com/unqueued/git-cache-tag

It copies all untracked stuff (including node_modules) into a leaf tag. It is fairly easy to manage them, or find the latest one. And because they are leaves, they can be pruned and completely garbage collected when they aren't useful anymore.

I have been burnt many times by npm, and I use this script to guarantee that I have a stash of my node_modules, while also keeping my project small.

And I have diffed different snapshot tags to see which module changed that broke something.

And by leaving everything in unaltered text, it exposes it to git which does a great job at compression stuff, especially highly differential revisions of my node_modules.

A 500M node_modules from one of my projects only weighed about 100M extra, even with several snapshots. And I can just delete them anyway.

I need to work on it a lot more, it was just a quick and dirty solution when I had to work with React Native a few years ago.

• git-archive-all

  2 9 0.0 Shell

  git-archive with recursive submodule support

Thanks for sharing!

Depending on the context, if you don't want this in git history, and want to handle git submodules, there's also git-archive-all https://github.com/roehling/git-archive-all (if you like shell scripts, it is using bats for testing - it was the first time I heard of it)

• Puts Debuggerer

  3,150 91 5.5 Ruby

  Ruby library for improved puts debugging, automatically displaying bonus useful information such as source line number and source code.

Suggestion how to manage node_modules: When testing different modules use npm/yarn, but once you have decided which module to use, fork the module on Github (most node_modules are on Github) then link directly to your fork in package.json like this: https://github.com/{user}/{module}/tarball/master

• go-offline-maven-plugin

  1 153 0.0 Java

  Maven Plugin used to download all Dependencies and Plugins required in a Maven build, so the build can be run without an internet connection afterwards.

  

For Maven, you can use this plugin to move downloading dependencies into a separate step:

https://github.com/qaware/go-offline-maven-plugin

It's not perfect, but it can be useful.

• depclean

  2 231 8.8 Java

  DepClean automatically detects and removes unused dependencies in Maven projects (https://dx.doi.org/10.1007/s10664-020-09914-8)

  

You can save yourself some headaches by not using transitive dependencies in your Maven builds. This can be enforced with Maven Enforcer. The trade-off is that you will have to clean unused dependencies. This can be tool-assisted with something like: https://github.com/castor-software/depclean/ . You can also enforce dependency version convergence with Maven Enforcer. None of this saves you from "jar hell" directly, but it helps prevent you from unknowingly creating a disaster-in-waiting.

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

Suggest a related project