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.
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.
so, you do concede it won't work on whatever Node version is current then.
how confident are you that Node 18 will run on whatever platform you're using then? or will you be stuck on a 2023 OS image also? will all the deps be available? will the many layers of tooling still work? will they work on Node 18, or will you need to get Node 18 and Node 2033 running in the same space? etc etc.
it's already a nightmare running things a year or two apart in time in the Node world, I would guess in 2033 you'd need an entire frozen-in-amber VM image with all tooling also frozen in the same amber/.