node/test/fixtures/require-path/p1/bar.js

var path = require('path');

require.paths.unshift(path.join(__dirname, '../p2'));

exports.foo = require('foo');

exports.expect = require(path.join(__dirname, '../p2/bar'));
exports.actual = exports.foo.bar;
GJSLint part of tests 2010-12-03 09:03:18 +08:00			`var path = require('path');`
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. 2010-07-16 01:41:40 +08:00
GJSLint part of tests 2010-12-03 09:03:18 +08:00			`require.paths.unshift(path.join(__dirname, '../p2'));`
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. 2010-07-16 01:41:40 +08:00
GJSLint part of tests 2010-12-03 09:03:18 +08:00			`exports.foo = require('foo');`
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. 2010-07-16 01:41:40 +08:00
GJSLint part of tests 2010-12-03 09:03:18 +08:00			`exports.expect = require(path.join(__dirname, '../p2/bar'));`
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. 2010-07-16 01:41:40 +08:00			`exports.actual = exports.foo.bar;`