> So there's an example of node-specific problem and there doesn't seem to be any impetus surrounding solving it.

??? There's so little impetus around solving it that both sides(npm and Microsoft) have put in significant effort to do it - npm 3 reduced the chance of having a very large path, and preview builds of the .net file api are removing the MAX_PATH limit.

https://github.com/Microsoft/nodejstools/issues/69

https://github.com/Microsoft/nodejs-guidelines/blob/master/w...

Fair enough, I'd strike-through that quip in my comment if I could. Still, this problem needs a bold/breaking fix. I most likely didn't run into this with my dev-testing because I am on a filesystem with reparse support.

Isn't the max path issue an operating system bug exposed because the tool you were using was designed to run on an OS without that bug?

You can't store an arbitrarily long path regardless of OS. EXT4 only pushes the value to 4096 - meaning that encountering this bug on Linux is only a matter of time. The unreasonably small value on Windows merely resulted in this boundary condition failing sooner.

Code merely pushes electrons around, meaning that it has constraints firmly rooted in physics. So no: NPM runs in a universe (regardless of OS) and fails to account for the constraints of that universe by falling into unbounded recursion far too easily. This could have all been avoided by correctly applying graph theory and/or prior wisdom in regard to dynamically loading modules - which has existed for decades. Now we're forced to kludge it with reparse/symlink and that only works on file systems with these features.

are you implying that design decision is good?

There is nothing wrong with using callbacks. Or promises. Or async/await. Or any other abstraction that makes sense for you.

This is a "writing code"-centric point of view. From the maintenance perspective "you" aren't the only person for whom the tradeoffs of callbacks/promises/async-await matter. It also matters to the people who have to come along years later and maintain the software.

So really it's about what abstraction makes sense for the maintainers as well. Not just you.

> people who have to come along years later and maintain

The problem is there is no way to know years in advance what makes sense for those future people. All you have is current standard at your org and/or common sense. Do what they say.

When you choose what the standard is, select whichever makes more sense at the moment. That is kind of my original point.

You may not know their own personal preference when writing code. But you can know what will make their job easier. Strong typing for instance will make refactoring easier. Good perf tooling will make analyzing performance easier and so on.