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.
a) create a layer of indirection in net.Stream to allow swapping in
different read/write implementations and
b) emit an 'fd' event when file descriptors are received over a UNIX pipe,
as finally as a tangential benefit
c) remove a bunch of conditionals from the primary codepaths for
ease-of-reading.
- No more single line "node.js:176:9" errors
- No more strange output when error happens on first line due to
module wrapper function.
- A few tests to check these things
Update the ini parser to support some more whitespace cases, turn lines
without an equal sign into a "flag" that's just true if set, and support
comments.
onExit() is similar to the onLoad() callback. onExit() is called on each
module just before the process exits. This can be used to check state in
unit tests, but not to perform I/O. The process will forcibly exit as soon
as all of the onExit callbacks are made.
There is one major API change in the refactor: filename extensions are now
required when requiring or including modules.
Added extra test to test-module-loading.js.
isaacs
Benjamin Fritsch
Ryan Dahl
Blake Mizerany
Peter Griess
Orlando Vazquez
Elijah Insua
Felix Geisendörfer
Jonas Pfenniger
Rhys Jones
Herbert Vojcik
Tim-Smart
Rob Ellis
arlolra