[RadiozRadioz]

It definitely won't run, but I can't tell you why. Nobody can tell you why, because everything in that ecosystem is such an immensely complicated & fragile mess that there's no telling what will break; anything's fair game. Random module pulled from NPM? Surprise build step that depends on a random combination of C libraries? People reflecting implementation details of other modules that get changed with a point release? Some world conflict somewhere evoking a blackout in libReplaceCommaWithUnderscore? I don't know, but I've spent too many days of my life debugging Node module installs on the latest version, I'm certain it won't be any easier in 10 years.

[Capricorn2481]

But we're not talking about installing the latest versions of your libraries. Otherwise, Go will definitely break after 10 years

[mayama]

Even with same lock file, modules that depend on native compilations will have problem with changing c compilers, libraries etc. Some libraries are fixed to minor version of node or node-gyp, so they won't compile with newer node. I had run into these issues both in both python and nodejs.

[RadiozRadioz]

Yes I know, the situations I described would apply if you used libraries with the same version 10 years from now.

In the case of the "internal dependency" one, plenty of people regularly patch stuff in NPM and keep the same version number.