Because Node modules are wrapped, errors on the first line
of a file leak the wrapper to the user and report the wrong
column number. This commit adds a line break to the module
wrapper so that the first line is treated the same as all
other lines. To compensate for the additional line, a line
offset of -1 is also applied to errors.
Fixes: https://github.com/nodejs/node/issues/2860
PR-URL: https://github.com/nodejs/node/pull/2867
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
`require.paths` property and `require.registerExtension` function have
been throwing errors when used. They both are like this for years now.
This patch removes them from the system.
PR-URL: https://github.com/nodejs/node/pull/2922
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Brian White <mscdex@mscdex.net>
Reviewed-By: Сковорода Никита Андреевич <chalkerx@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
common.debug() is just util.debug() and emits a deprecation notice. Per
docs, use console.error() instead.
PR-URL: https://github.com/nodejs/node/pull/3082
Reviewed-By: Michaël Zasso <mic.besace@gmail.com>
Enable linting for the test directory. A number of changes was made so
all tests conform the current rules used by lib and src directories. The
only exception for tests is that unreachable (dead) code is allowed.
test-fs-non-number-arguments-throw had to be excluded from the changes
because of a weird issue on Windows CI.
PR-URL: https://github.com/nodejs/io.js/pull/1721
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
Module.globalPaths is still set to a read-only copy of the global
include paths pulled off of the NODE_PATH environment variable.
It's important to be able to inspect this, but modifying it no longer
has any effect.
This adds basic support for situations where there is a package.json
with a "main" field. That "main" module is used as the code that is
loaded when the package folder is required.
Currently the module tests don't cover the cases for when a user
requires a file with a request that includes the extension, and for a
request to a file with no extensions.
ex.
require("./a.js") // not tested
require("./foo") // (not tested with trying to load a file named ./foo)
This patch removes require.async from nodejs.
1. It complicated the code unnecessarily.
2. Everyone uses sync require anyway.
3. It's got a lot of weird edge cases when mixed with sync require.
4. It is many months behind the commonjs spec anyhow.
This patch standardises the load order for modules. Highest priority is trying to load exactly the file the user specified, followed by native extensions, followed by registered extra extensions, etc.
In full, if we require('foo') having registered '.coffee' as an alternative extension, we try and load the following files in order:
foo
foo.js
foo.node
foo.coffee
foo/index.js
foo/index.node
foo/index.coffee
This patch replaces the path.exists check for module loading with a call to
fs.statSync (or fs.stat for require.async) which ensures that it's not trying
to load a directory.
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.
Michaël Zasso
cjihrig
Tristian Flanagan
Sakthipriyan Vairamani
Rich Trott
Roman Reiss
isaacs
Fedor Indutny
Felix Böhm
Bert Belder
Igor Zinkovsky
Ryan Dahl
Ben Noordhuis
Colton Baker
Oleg Efimov
Anders Conbere
Tim-Smart
Herbert Vojčík
Nick Stenning
David Siegel
Tim-Smart