2 ms·

Because package-lookup and the package manager are 2 completely separate systems in javascript. When you `require` or `import` a file in node.js, it looks for

Because package-lookup and the package manager are 2 completely separate systems in javascript. When you `require` or `import` a file in node.js, it looks for a node_modules and looks for that name in there. If it can't find it there, it starts walking up the directory tree until it finds something it can use (to a point). This is hardcoded and will be extremely difficult to change without a crazy amount of breaking. The package manager is free to install however, but it needs to put things where the package-lookup can find them.

smrtinsert 10y ago
Everyone knows it shouldn't be. Even a naive attempt by the average developer to write a package management system would take versions into account.
- Klathmon 10y ago
  Again, it's not the package management system that is the problem, it's the module loader in node.js. And it's easy to say "even a naive attempt by the average developer" would do it better, but I really don't think they would have. Still, the fact is that this is what we have, and complaining about what could have been isn't going to do anyone any good, improving the system will.
sah2ed 10y ago
But it is still possible to have the best of both worlds. Essentially, all they need to do is: 1. leave the current behavior for backwards compatibility; then 2. provide a flag like npm -G that exposes the correct behavior as suggested in the grand parent of using the same path like SHARED_DIR/node_modules/NAME/VERSION for package imports and package management. With time, newer npm versions will default to the correct behavior. For folks that need backwards compatibility, this would require explicitly setting a npm --compat flag or similar.
- Klathmon 10y ago
  The problem isn't in the "package manager" it's in node.js node loads modules in a given pattern. Changing that pattern would be global to your project, and would cause issues with tons of 3rd party tools. the best possible scenario would be to introduce a "new_node_modules" type directory and change to the new system, then look in "new_node_modules" first, then the legacy "node_modules" next, but that's a ton of work, a ton of 3rd party tool breakage, and a lot of possibility for new bugs and breakage for not all that much benefit. That's not to say it shouldn't be done at some point, just that there are much bigger areas that need to be addressed sooner in the node ecosystem.
  - moderndeveloper 10y ago
    node's module resolution will not likely ever be fixed. Too many modules depend on its undocumented implementation details and there isn't the will to improve it. A major source of problems is node's symlink resolution scheme that depends on fully resolved paths, counter to how other UNIX programs use files. Because many module developers know how the resolution scheme works they often hard code behaviors and paths into their code that would basically prevent any alternative module resolution scheme from working.

smrtinsert 10y ago

Everyone knows it shouldn't be. Even a naive attempt by the average developer to write a package management system would take versions into account.

Klathmon 10y ago
Again, it's not the package management system that is the problem, it's the module loader in node.js. And it's easy to say "even a naive attempt by the average developer" would do it better, but I really don't think they would have. Still, the fact is that this is what we have, and complaining about what could have been isn't going to do anyone any good, improving the system will.

sah2ed 10y ago

But it is still possible to have the best of both worlds. Essentially, all they need to do is: 1. leave the current behavior for backwards compatibility; then 2. provide a flag like npm -G that exposes the correct behavior as suggested in the grand parent of using the same path like SHARED_DIR/node_modules/NAME/VERSION for package imports and package management. With time, newer npm versions will default to the correct behavior. For folks that need backwards compatibility, this would require explicitly setting a npm --compat flag or similar.

Klathmon 10y ago
The problem isn't in the "package manager" it's in node.js node loads modules in a given pattern. Changing that pattern would be global to your project, and would cause issues with tons of 3rd party tools. the best possible scenario would be to introduce a "new_node_modules" type directory and change to the new system, then look in "new_node_modules" first, then the legacy "node_modules" next, but that's a ton of work, a ton of 3rd party tool breakage, and a lot of possibility for new bugs and breakage for not all that much benefit. That's not to say it shouldn't be done at some point, just that there are much bigger areas that need to be addressed sooner in the node ecosystem.
- moderndeveloper 10y ago
  node's module resolution will not likely ever be fixed. Too many modules depend on its undocumented implementation details and there isn't the will to improve it. A major source of problems is node's symlink resolution scheme that depends on fully resolved paths, counter to how other UNIX programs use files. Because many module developers know how the resolution scheme works they often hard code behaviors and paths into their code that would basically prevent any alternative module resolution scheme from working.