undefined | Better HN

0 pointssah2ed9y ago0 comments

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.

0 comments

Klathmon9y 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.

moderndeveloper9y 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.

j / k navigate · click thread line to collapse