6 ms·

> Really? There is no more "problem" with Node.js than there is a "problem" with any other platform. While I agree in principle, I've been bitten by some incre

by zamalek 10y ago

> Really? There is no more "problem" with Node.js than there is a "problem" with any other platform. While I agree in principle, I've been bitten by some incredibly bad node packaging architectural decisions. Just yesterday I was attempting to install tfx-cli in order to CICD our build scripts to our build server - it went as you would expect with npm: MAX_PATH issues. The git clean then failed on all subsequent builds. A problem became unsolvable by virtue of the platform that was used to write it - had tfx-cli been written in almost anything else, this would not have been a problem (I say "almost" because I'm egregiously assuming that at least one other package manager is also broken in this way). So there's an example of node-specific problem and there doesn't seem to be any impetus surrounding solving it. > Oh but look at that callback YUCK! Cmon In defense of Node, it now supports ES6: callback hell is self-imposed for all new code.

iends 10y ago
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?
- baq 10y ago
  are you implying that design decision is good?
- zamalek 10y ago
  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.
Sacho 10y ago
> 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/nodejstools/issues/69 https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#max_path-explanation-and-workarounds https://github.com/Microsoft/nodejs-guidelines/blob/master/w...
- zamalek 10y ago
  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.
elmigranto 10y ago
There is nothing wrong with using callbacks. Or promises. Or async/await. Or any other abstraction that makes sense for you.
- zaphar 10y ago
  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.
  - elmigranto 10y ago
    > 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.
    - zaphar 10y ago
      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.

by zamalek 10y ago

iends 10y ago

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?

baq 10y ago
are you implying that design decision is good?
zamalek 10y ago
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.

Sacho 10y ago

> 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/nodejstools/issues/69 https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#max_path-explanation-and-workarounds https://github.com/Microsoft/nodejs-guidelines/blob/master/w...

zamalek 10y ago
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.

elmigranto 10y ago

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

zaphar 10y ago
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.
- elmigranto 10y ago
  > 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.
  - zaphar 10y ago
    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.