5 ms·

Can I browse my node_modules folder in Explorer yet? [1] [1] https://github.com/joyent/node/issues/6960 https://github.com/joyent/node/issues/6960

by cmwelsh 11y ago

rational-future 11y ago
With every new version of Windows, Explorer gets worse and worse. I personally switched to Directory Opus long time ago.
- chimeracoder 11y ago
  > With every new version of Windows, Explorer gets worse and worse. This criticism is a bit misplaced here, since the whole reason for this limitation is due to backward compatibility with older versions of Windows (and software written for older versions). It's not like this is a new change in Windows; it's been there for ages.
- orik 11y ago
  This isn't a limitation of Explorer, but actually is a very well documented part of the Windows API. MAXPATH has always been 260 characters. https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/aa365247(VS.85).asp...
  - frik 11y ago
    How long will Microsoft wait till the fix MAXPATH and other limitations? (and various other Win32 limitations that are usually a legacy porting helper thing from Win16). There would have been a good point with the introduction of Win64API - but Microsoft forgot about it and was apparently busy with something else.
    - CHY872 11y ago
      I doubt it's too high up on the list of priorities. It would require really careful work to work in a backwards compatible way (there are almost certainly a tonne of apps that expect <=260 character filenames). I guess the main thing is that it's one of those 'who cares' problems. The only time I've ever seen this limitation being complained about, it's by people who've had problems with npm. That directory structure is undoubtedly horrible and is not mirrored by any other piece of software that I've seen.
      - jessaustin 11y ago
        Meanwhile it's also a "who cares?" problem for the npm people. They don't use this OS, and don't expect ever to do so. I think the node_modules directory structure is a novel, though straightforward, solution to the problem of interdependent module versioning. It's very Unix; it reminds me a bit of GNU stow. It makes perfect sense that it will be tweaked in the new npm to be less redundant, but it only really makes sense to tweak systems that already work perfectly. (Otherwise they should be fixed first, then tweaked.) Certainly it's better than having a separate LD_LIBRARY_PATH setting for every command invocation! (even that doesn't fix everything...)
        xienze 11y ago
        It doesn't even seem like an obvious solution to the problem. Take Maven for instance: a global dependency repository under which the dependencies are stored in the form <groupId>/<artifactId>/<version>. If X depends on Y.1 and Z depends on Y.2, so what? You have all the dependencies stored on your filesystem in a relatively flat structure.
        jessaustin 11y ago
        If I had coded in Java on Windows for years, I wouldn't trust my sense of what's "obvious". I'm not too impressed by a "global" repository either. Python struggled against that stupid architecture for years before they got virtualenv in good working order. Node just took a shortcut to the future. "All direct dependencies are in the node_modules directory, full-stop" is a pretty simple rule. Really, that's the only rule, and that's all of it. You don't need to worry about second-order dependencies, because those are direct dependencies of some other module, which means... they are in that module's node_modules directory.
      - ygra 11y ago
        I had the problems with a Java codebase in SVN (back when your user profile was still under C:\Dokumente und Einstellungen\Username\... Apart from that there is a backwards-compatible way of using longer paths, which is prefixing with \\?\. Since MAX_PATH is a hard-coded constant there can only be an opt-in way of dealing with the problem. Sadly many application or framework developers these days still don't opt in. It also creates the problem that if Application A can create such paths and Application B cannot read them, you'll be annoyed too. And Application A might just disable long path support to mitigate the problem, leaving the whole state as it is.
  - efdee 11y ago
    It is a limitation of Explorer and CMD.EXE - Windows has had Unicode APIs to access paths up to 32767 characters, but for some reason they have Explorer and CMD.EXE use the older ANSI API which does not support it.
dyscrete 11y ago
Wow, what's up Microsoft?
- pionar 11y ago
  Actually, I was thinking, what's up node? Each dependency keeps a private copy of its dependencies? How messed up is that? Or am I just reading that wrong?
  - bryanlarsen 11y ago
    That's a feature, not a bug. It lets A rely on version 0.9 of X while B relies on version 0.8.
    - pionar 11y ago
      I don't call that a feature. There's other ways of doing version pinning without junking up my filesystem.
      - tdicola 11y ago
        Regardless of who is right or wrong at the end of the day it's still broken for many people. If Microsoft and Joyent/the node & npm community care about people using node & npm on Windows then the issues needs to be resolved, period.
    - ksherlock 11y ago
      That can introduce other problems. https://news.ycombinator.com/item?id=8213273 https://news.ycombinator.com/item?id=8213273 http://i.imgur.com/AZJti8I.png http://i.imgur.com/AZJti8I.png
      - nemothekid 11y ago
        I don't see how this npm's problem - the language itself doesn't let you catch this problem - and the pattern itself is dangerous. I'd have to agree with IsaacSchlueter here. If I have a library (libA) that uses fooV1 and another (libB) that uses fooV2, there is no reason I should expect those two dependencies to interop with each other (except explicitly stated by the developer). The solution (that there should be one set of dependencies) is an even worse problem that currently afflicts the Golang community, which they have decided to solve the same way npm has decided to solve it - vendoring. Now with Golang, if you only have 1 set of dependancies, and one of your libraries depended on an older version - your program just won't compile (unless you update the library to use fooV2) and I'm not sure how thats useful to anyone. Most people will just tell you should have have just versioned that dependency.

Can I browse my node_modules folder in Explorer yet? [1] [1] https://github.com/joyent/node/issues/6960 https://github.com/joyent/node/issues/6960

by cmwelsh 11y ago

Can I browse my node_modules folder in Explorer yet? [1] [1] https://github.com/joyent/node/issues/6960 https://github.com/joyent/node/issues/6960

rational-future 11y ago

With every new version of Windows, Explorer gets worse and worse. I personally switched to Directory Opus long time ago.

chimeracoder 11y ago
> With every new version of Windows, Explorer gets worse and worse. This criticism is a bit misplaced here, since the whole reason for this limitation is due to backward compatibility with older versions of Windows (and software written for older versions). It's not like this is a new change in Windows; it's been there for ages.
orik 11y ago
This isn't a limitation of Explorer, but actually is a very well documented part of the Windows API. MAXPATH has always been 260 characters. https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath https://msdn.microsoft.com/en-us/library/aa365247(VS.85).asp...
- frik 11y ago
  How long will Microsoft wait till the fix MAXPATH and other limitations? (and various other Win32 limitations that are usually a legacy porting helper thing from Win16). There would have been a good point with the introduction of Win64API - but Microsoft forgot about it and was apparently busy with something else.
  - CHY872 11y ago
    I doubt it's too high up on the list of priorities. It would require really careful work to work in a backwards compatible way (there are almost certainly a tonne of apps that expect <=260 character filenames). I guess the main thing is that it's one of those 'who cares' problems. The only time I've ever seen this limitation being complained about, it's by people who've had problems with npm. That directory structure is undoubtedly horrible and is not mirrored by any other piece of software that I've seen.
    - jessaustin 11y ago
      Meanwhile it's also a "who cares?" problem for the npm people. They don't use this OS, and don't expect ever to do so. I think the node_modules directory structure is a novel, though straightforward, solution to the problem of interdependent module versioning. It's very Unix; it reminds me a bit of GNU stow. It makes perfect sense that it will be tweaked in the new npm to be less redundant, but it only really makes sense to tweak systems that already work perfectly. (Otherwise they should be fixed first, then tweaked.) Certainly it's better than having a separate LD_LIBRARY_PATH setting for every command invocation! (even that doesn't fix everything...)
      - xienze 11y ago
        It doesn't even seem like an obvious solution to the problem. Take Maven for instance: a global dependency repository under which the dependencies are stored in the form <groupId>/<artifactId>/<version>. If X depends on Y.1 and Z depends on Y.2, so what? You have all the dependencies stored on your filesystem in a relatively flat structure.
        jessaustin 11y ago
        If I had coded in Java on Windows for years, I wouldn't trust my sense of what's "obvious". I'm not too impressed by a "global" repository either. Python struggled against that stupid architecture for years before they got virtualenv in good working order. Node just took a shortcut to the future. "All direct dependencies are in the node_modules directory, full-stop" is a pretty simple rule. Really, that's the only rule, and that's all of it. You don't need to worry about second-order dependencies, because those are direct dependencies of some other module, which means... they are in that module's node_modules directory.
    - ygra 11y ago
      I had the problems with a Java codebase in SVN (back when your user profile was still under C:\Dokumente und Einstellungen\Username\... Apart from that there is a backwards-compatible way of using longer paths, which is prefixing with \\?\. Since MAX_PATH is a hard-coded constant there can only be an opt-in way of dealing with the problem. Sadly many application or framework developers these days still don't opt in. It also creates the problem that if Application A can create such paths and Application B cannot read them, you'll be annoyed too. And Application A might just disable long path support to mitigate the problem, leaving the whole state as it is.
- efdee 11y ago
  It is a limitation of Explorer and CMD.EXE - Windows has had Unicode APIs to access paths up to 32767 characters, but for some reason they have Explorer and CMD.EXE use the older ANSI API which does not support it.

dyscrete 11y ago

Wow, what's up Microsoft?

pionar 11y ago
Actually, I was thinking, what's up node? Each dependency keeps a private copy of its dependencies? How messed up is that? Or am I just reading that wrong?
- bryanlarsen 11y ago
  That's a feature, not a bug. It lets A rely on version 0.9 of X while B relies on version 0.8.
  - pionar 11y ago
    I don't call that a feature. There's other ways of doing version pinning without junking up my filesystem.
    - tdicola 11y ago
      Regardless of who is right or wrong at the end of the day it's still broken for many people. If Microsoft and Joyent/the node & npm community care about people using node & npm on Windows then the issues needs to be resolved, period.
  - ksherlock 11y ago
    That can introduce other problems. https://news.ycombinator.com/item?id=8213273 https://news.ycombinator.com/item?id=8213273 http://i.imgur.com/AZJti8I.png http://i.imgur.com/AZJti8I.png
    - nemothekid 11y ago
      I don't see how this npm's problem - the language itself doesn't let you catch this problem - and the pattern itself is dangerous. I'd have to agree with IsaacSchlueter here. If I have a library (libA) that uses fooV1 and another (libB) that uses fooV2, there is no reason I should expect those two dependencies to interop with each other (except explicitly stated by the developer). The solution (that there should be one set of dependencies) is an even worse problem that currently afflicts the Golang community, which they have decided to solve the same way npm has decided to solve it - vendoring. Now with Golang, if you only have 1 set of dependancies, and one of your libraries depended on an older version - your program just won't compile (unless you update the library to use fooV2) and I'm not sure how thats useful to anyone. Most people will just tell you should have have just versioned that dependency.