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

3252 Commits

131 Branches

446 Tags

325 MiB

Tree: eb57d1b9b1

Commit Graph

Author	SHA1	Message	Date
Oleg Efimov	c0d69a4883	GJSLint part of tests	14 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

Author

SHA1

Message

Date

Oleg Efimov

c0d69a4883

GJSLint part of tests

14 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

2 Commits (eb57d1b9b197a0d5be6047c0d5e653468f73cac7)