Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flat Tree Dependency Resolution in Npm v3

docs.npmjs.com

Post reply on HN
Print view View original

91–100 of 123 posts

Re: Flat Tree Dependency Resolution in Npm v3

#91

Post by tracker1 »

feross wrote: post #39
ploxiln wrote: post #35

Earlier quoted context omitted.

This "penalty" you propose would be a cosmetic thing, it wouldn't really make a difference. Many devs would choose to use the module as a dependency of their modules. The real solution to the sub-dependency-insanity of npm is ... use fewer dependencies. Don't use dependencies that have sub-dependencies. Write more code to directly solve your problem. This is a viewpoint you won't often hear, because it comes from som…

I wouldn't recommend using fewer dependencies, but smaller ones. One of the best features of npm is that it solves the "dependency hell" problem. You can depend on modules freely and not worry about making it harder for users of your module to install it. The issue comes when people create these huge "do-everything" modules. This is worth a read: https://github.com/sindresorhus/ama/issues/10#issuecomment-1...

where this really starts to bite in my mind, is when you wind up seeing multiple modules in different dependencies that do the same thing.

Lodash, Underscore, Ramda and other come to mind in particular here... It's really easy to wind up with at least two of those three. Part of why I wouldn't mind seeing a few "winners" even if slightly larger win out. We're at a point where we get to tear jQuery out of projects, but it's easy enough to wind up with bundles that are larger than if we'd just used jQuery or Zepto, or whatever.

Re: Flat Tree Dependency Resolution in Npm v3

#92

Post by tracker1 »

city41 wrote: post #87
moron4hire wrote: post #61

Earlier quoted context omitted.

>> Windows is very much an outlier in the world of software development. Unless you're specifically using Microsoft tech (ie .NET and all that) I think you need to get out more. Or at least go to meetups that don't only meet at coffee shops. You're cutting out a huge chunk there, and there are still huge chunks that use Windows to do Java, C++, etc. I mean, game development is a multi billion dollar industry that is…

>> This is different from Apple with OSX and iOS how? I'll never run "npm install" or "gem install" or what have you on iOS, Android, etc. Proprietary OSes come in all shapes and sizes, all bringing their own pros and cons to the mix. I just happen to be focusing on a very large con of Windows at the moment. As for OSX, Redhat, Debian, etc. Sure, they're all different, of course. But generally speaking, at least when…

Given windows is the vast majority of desktops, and that there is more variety between different Linux distros and OSX versions than there are in the decades of Windows APIs, I think you have things a little backwards.

I've done far more dev targeting linux deployments the past few years, and much of it is far nicer on *nix than windows... but your viewpoint seems to be kind of arrogant. I haven't worked for a company that has more than 100 employees that doesn't do most development on windows, even if that isn't the target for deployment. That includes two major financial institutions, some large internet services and many other smaller companies over the years.

Re: Flat Tree Dependency Resolution in Npm v3

#93

Post by ag_dubs »

city41 wrote: post #49
ag_dubs wrote: post #41

Earlier quoted context omitted.

hi! i totally know this is a common feel for many npmjs users. this is why i've been running an empathy campaign for Windows, Windows Wednesday, where i do all my work (with/for npm) on windows. it's been good for finding bugs, either technical or UX. i'm working on improving the docs to make them friendlier to all platforms (not just OSX, which is the most common platform at npmjs). npmjs cares about the enterprise…

I think this is the wrong approach. We shouldn't pick up MS's slack, MS should. This just enforces the current situation and keeps enabling MS to ignore the problem.

you might also consider the fact that OSX machines are expensive. and the education for learning linux is generally expensive or not accessible. so supporting windows also supports ... poor people, people from different countries that have different economies, etc.

should we not pick up capitalism's slack? capitalism sure isn't going to pick up its own slack, err... systemic method of restricting underprivileged/poor people's access to power.

Re: Flat Tree Dependency Resolution in Npm v3

#94

Post by tracker1 »

martindevans wrote: post #67
gelasio wrote: post #59

Earlier quoted context omitted.

"But they make little to no effort to help bridge the gap, they usually leave that to everyone else." OK, but that's also where you're wrong, right there. In general, but also particularly for this exact issue - Microsoft considered attempting to fix the file path limit for the first release of Windows 10. Maybe you don't understand, but it's going to take a herculean effort to fix this. They want to do it and if you…

Don't UNC paths solve this problem already (30000+ char limit)?

The problem is the default/legacy APIs don't use the new paths... in .Net I had this problem a lot, and serious issues every method I tried to work around it would hard crash VS, let alone the application I was working on... in the end, after days trying the solution was to say f*ck it and just put the directory I was working with closer to the root of the drive in question.

Why they can't fix .Net under the covers to use UNC in windows to avoid the class of problem I don't know, understand or comprehend... and that's just one very common platform for windows. I would say the same for npm/node and libuv for that matter.

I use bash a lot in windows (installed with msysgit), and that's got it's own set of problems. More problematic is the number of node modules that rely on bash scripts for builds, that don't work at all in windows.... which makes it very hard to contribute.

Re: Flat Tree Dependency Resolution in Npm v3

#95

Post by tracker1 »

tehnorm wrote: post #40
kylecordes wrote: post #8

I understand that this is a hairy, messy problem they are solving, and that they traded off one aspect of the problem for another (Install order dependency! as a new "feature" in 2015!). But I wish they had aimed higher. The better goal would be that the entire state of the node modules directory is a pure function of the contents of the package.json file plus the platform details (compiler used for native modules).…

Aimed higher is correct. I've always wondered why no one looked at the way git does this under the covers and applied it to npm. A directed graph that points to (with a sym link or similar mechanism) the correct package version on the file system. That way you have the best of both worlds - dependencies don't collide and a single copy of a package version on the file system in node_modules.

The biggest bug is that Windows Explorer gui has troubles with long file paths.

Re: Flat Tree Dependency Resolution in Npm v3

#96

Post by davexunit »

Touche wrote: post #77
Arcsech wrote: post #71

Earlier quoted context omitted.

The aforementioned GNU Guix and the similar Nix project are exactly that: Cross-platform (mostly, at least Nix requires a unixy layer on Windows) language-independent package managers. One could argue that they aren't "successful" (in that they don't have all the packages you might want), but they are still quite new and are pretty different from traditional package managers. I believe that Nix/Guix are the future, b…

> Cross-platform (mostly, at least Nix requires a unixy layer on Windows) Not good enough, language package managers must work on Windows, with a regular command prompt.

Windows is hopeless. If Windows is a must, you really cannot do much better than a package manager per language that you use. No binary reproducibility, no transactional management, no provenance, no thanks.

Re: Flat Tree Dependency Resolution in Npm v3

#97

Post by davexunit »

nawitus wrote: post #64
davexunit wrote: post #43

Earlier quoted context omitted.

>This is what we did with Dart's package manager[1]. It works like Bundler where it finds a single set of package versions that satisfy all of the constraints and there are no duplicate packages. Constraint solving is the status quo, and I am strongly opposed to it. Rather than saying "I want foo >= 1.0" in a package manager, you should have the build system test the environment for the features you need. This is wha…

Language specific package managers seem to actually work in real life and are cross platform, e.g. npm. But I'm not aware of anything for e.g. C++ which would offer the features of npm (mainly installing dependencies with a single command and supporting GNU/Linux, OS X and Windows). Is there a single non-language specific package manager which is cross platform, and supports a large percentage of packages for a given…

>'m not aware of a single successful language-independent package manager

Ummmm... dpkg and yum? You know, the package managers that manage the software on everyone's production servers. Or do these not count because they don't work on Windows or something?

Re: Flat Tree Dependency Resolution in Npm v3

#98

Post by city41 »

tracker1 wrote: post #92
city41 wrote: post #87

Earlier quoted context omitted.

>> This is different from Apple with OSX and iOS how? I'll never run "npm install" or "gem install" or what have you on iOS, Android, etc. Proprietary OSes come in all shapes and sizes, all bringing their own pros and cons to the mix. I just happen to be focusing on a very large con of Windows at the moment. As for OSX, Redhat, Debian, etc. Sure, they're all different, of course. But generally speaking, at least when…

Given windows is the vast majority of desktops, and that there is more variety between different Linux distros and OSX versions than there are in the decades of Windows APIs, I think you have things a little backwards. I've done far more dev targeting linux deployments the past few years, and much of it is far nicer on *nix than windows... but your viewpoint seems to be kind of arrogant. I haven't worked for a compan…

I don't mean to be arrogant, and if I am honestly it comes from ignorance. I've worked in MS shops before (I did .NET, COM, etc for nearly a decade). This whole thing blew up out of frustration at Windows specific issues cropping up more often than any other OS in environments like Node. I do think that's hard to deny. If that's arrogant, then I don't know what to say :-/

Re: Flat Tree Dependency Resolution in Npm v3

#99

Post by city41 »

moron4hire wrote: post #89
city41 wrote: post #87

Earlier quoted context omitted.

>> This is different from Apple with OSX and iOS how? I'll never run "npm install" or "gem install" or what have you on iOS, Android, etc. Proprietary OSes come in all shapes and sizes, all bringing their own pros and cons to the mix. I just happen to be focusing on a very large con of Windows at the moment. As for OSX, Redhat, Debian, etc. Sure, they're all different, of course. But generally speaking, at least when…

I don't think you realize just how different even various Linux distros running even the same kernel can be, and I think you're giving waaay too much credit to OSX/Linux for being "alike". MAKE build scripts have notoriously been a mess for decades because of the differences between distros. Any reasonable language has the ability to query all of the platform-specific stuff directly from the standard library. You can…

I do get that. I totally understand all OSes are very different. How often those differences surface really depends on a lot of things, mostly at what level of the OS you are working in. Node modules and apps tend to stay pretty high level. But again, I still stand by my original statement that Windows specific issues crop up more than any other OS. Just take a look at the README for node-gyp: https://github.com/nodejs/node-gyp -- yup in OSX you have to get Xcode and a few other OSX specific steps to arrive at gcc and make, but compare that to the Windows section ...

Re: Flat Tree Dependency Resolution in Npm v3

#100

Post by bhouston »

I do not understand why they just didn't have a two level directory structure:

node_modules/[module_name]/[version]

Then it would be flat and support multiple versions of the same module in a way that is completely deterministic and also fully deduplicated.

This new system is unnecessarily complex.

Post reply on HN