lukechilds/node - node - Gitea: Git with a cup of tea

Tree: c5eb1b55d9

isaacs 49e0f14a2f Cache modules based on filename rather than ID This is ever so slightly less efficient than caching based on ID, since the filename has to be looked up before we can check the cache. However, it's the most minimal approach possible to get this change in place. Since require() is a blocking startup-time operation anyway, a bit of slowness is not a huge problem. A test involving require.paths modification and absolute loading. Here's the gist of it. Files: /p1/foo.js /p2/foo.js 1. Add "/p1" to require.paths. 2. foo1 = require("foo") 3. assert foo1 === require("/p1/foo") (fail) 4. Remove /p1 from require.paths. 5. Add /p2 to require.paths. 6. foo2 = require("foo") 7. assert foo1 !== foo2 (fail) 8. assert foo2 === require("/p2/foo") (fail) It's an edge case, but it affects how dependencies are mapped by npm. If your module requires foo-1.2.3, and my module requires foo-2.3.4, then you should expect to have require("foo") give you foo-1.2.3, and I should expect require("foo") to give me foo-2.3.4. However, with module ID based caching, if your code loads first, then your "foo" is THE "foo", so I'll get your version instead of mine. It hasn't yet been a problem, but only because there are so few modules, and everyone pretty much uses the latest version all the time. But as things start to get to the 1.x and 2.x versions, it'll be an issue, I'm sure. Dependency hell isn't fun, so this is a way to avoid it before it strikes.	15 years ago
..
bar.js	Cache modules based on filename rather than ID	15 years ago
foo.js	Cache modules based on filename rather than ID	15 years ago

isaacs 49e0f14a2f Cache modules based on filename rather than ID

This is ever so slightly less efficient than caching based on ID, since the
filename has to be looked up before we can check the cache.  However, it's
the most minimal approach possible to get this change in place.  Since
require() is a blocking startup-time operation anyway, a bit of slowness is
not a huge problem.

A test involving require.paths modification and absolute loading. Here's the
gist of it.

Files: /p1/foo.js /p2/foo.js

  1. Add "/p1" to require.paths.
  2. foo1 = require("foo")
  3. assert foo1 === require("/p1/foo") (fail)
  4. Remove /p1 from require.paths.
  5. Add /p2 to require.paths.
  6. foo2 = require("foo")
  7. assert foo1 !== foo2 (fail)
  8. assert foo2 === require("/p2/foo") (fail)

It's an edge case, but it affects how dependencies are mapped by npm.
If your module requires foo-1.2.3, and my module requires foo-2.3.4,
then you should expect to have require("foo") give you foo-1.2.3, and
I should expect require("foo") to give me foo-2.3.4.  However, with
module ID based caching, if your code loads *first*, then your "foo"
is THE "foo", so I'll get your version instead of mine.

It hasn't yet been a problem, but only because there are so few
modules, and everyone pretty much uses the latest version all the
time.  But as things start to get to the 1.x and 2.x versions, it'll
be an issue, I'm sure.  Dependency hell isn't fun, so this is a way to
avoid it before it strikes.

15 years ago

bar.js

Cache modules based on filename rather than ID

15 years ago

foo.js

Cache modules based on filename rather than ID

15 years ago