5 ms·

Because then they'd have to change the semantics of how `require()` works. As it is, node packages are not version aware at runtime. Instead NPM is designed t

by vec 11y ago

Because then they'd have to change the semantics of how `require()` works. As it is, node packages are not version aware at runtime. Instead NPM is designed to place packages such that any library will have the correct version first in their load path. Changing the directory structure to encode versions is probably the Right Way in a grand sense, but it's a much more substantial change than just promoting packages by default.

theGimp 11y ago
I thought about that, but clearly they have enough information to figure out whether to load the package from the top level or a nested directory. (I'm guessing simply by bubbling up and looking for the "node_packages" directory.) It doesn't seem too big of a leap to do it the way I was suggesting. Either bubble up and look for "node_packages", but this time store a symlink there, or add a dot file that tells you "this is where I found package.json". I'm sure there was a reason they didn't go for either of those solutions because I've followed the team's discussions when they were iojs, and they have very smart people. I was just curious about the reasoning :)
- boucher 11y ago
  The information may be available, but ultimately the work would have to be done by node, not npm, and it seems reasonable to not want to change such a fundamental node behavior, especially just to support a change in npm.
  - theGimp 11y ago
    Ah, fair enough. I assumed the same team was in charge of both.
    - vec 11y ago
      Probably a lot of overlap, but they're separate projects with different versions and release schedules.
- JaRail 11y ago
  That doesn't handle peer dependencies. Those are resolved by walking up the filesystem. You can't walk up the file system with a symlinked structure. A single npm can be resolving different peer dependencies depending on where it is in the tree.
moron4hire 11y ago
Read the next-highest package.json file for whatever code is executing (dependencies copy their package.json file when they install), find the dependency listing in there, with the desired version constraint. If none exists (i.e. the dependency was installed manually), take wahtever is the highest version by default. If that's not what the developer wants, it's their own fault for not specifying the dependency in their package file.

by vec 11y ago

theGimp 11y ago

I thought about that, but clearly they have enough information to figure out whether to load the package from the top level or a nested directory. (I'm guessing simply by bubbling up and looking for the "node_packages" directory.) It doesn't seem too big of a leap to do it the way I was suggesting. Either bubble up and look for "node_packages", but this time store a symlink there, or add a dot file that tells you "this is where I found package.json". I'm sure there was a reason they didn't go for either of those solutions because I've followed the team's discussions when they were iojs, and they have very smart people. I was just curious about the reasoning :)

boucher 11y ago
The information may be available, but ultimately the work would have to be done by node, not npm, and it seems reasonable to not want to change such a fundamental node behavior, especially just to support a change in npm.
- theGimp 11y ago
  Ah, fair enough. I assumed the same team was in charge of both.
  - vec 11y ago
    Probably a lot of overlap, but they're separate projects with different versions and release schedules.
JaRail 11y ago
That doesn't handle peer dependencies. Those are resolved by walking up the filesystem. You can't walk up the file system with a symlinked structure. A single npm can be resolving different peer dependencies depending on where it is in the tree.

moron4hire 11y ago

Read the next-highest package.json file for whatever code is executing (dependencies copy their package.json file when they install), find the dependency listing in there, with the desired version constraint. If none exists (i.e. the dependency was installed manually), take wahtever is the highest version by default. If that's not what the developer wants, it's their own fault for not specifying the dependency in their package file.