`fs.fileReadSync` doesn't understand `file://` URL strings

[ravinggenius]

• Version: 10.0.0
• Platform: Darwin dionysus.local 17.5.0 Darwin Kernel Version 17.5.0: Mon Mar 5 22:24:32 PST 2018; root:xnu-4570.51.1~1/RELEASE_X86_64 x86_64
• Subsystem: fs

Description

Assume /tmp/foo.txt exist. Reading the file with fs.fileReadSync('/tmp/foo.txt') works as expected, but using fs.fileReadSync('file:///tmp/foo.txt') fails to read the file.

Why it matters

I need to read files relative to the current file, but __dirname/__filename are not available when parsing modules. I can compute __dirname with import.meta.url by passing it to path.dirname, but the path is still prefixed with file://.

[targos]

I don't remember why it's the case, but I think it is intended that fs methods don't accept URL strings. /cc @jasnell

What you can do instead is create an URL object like so:

const url = new URL(import.meta.url);
fs.readFileSync(url)

[jasnell]

Yep, this is intentional. The reason is because it would be a non-compatible breaking change and would introduce a non-trivial performance regression even for the common cases.

[TimothyGu]

Duplicate of #17658.

[neroux]

Any reason why import.meta.url.replace('file://', '') would not work?

[TimothyGu]

@neroux You need some extra handling for URL percent encoding. Generally, some weirdnesses around encoded / characters need to be taken care of with file: URLs, but because import.meta.url can be trusted to always represent a valid file path that's not necessary. Additionally, on Windows one would need to also handle UNC paths which may have punycode-encoded hostnames.

See following, which is our implementation of a general purpose URL-to-file path converter

node/lib/internal/url.js

Lines 1335 to 1386 in b55a11d

	function getPathFromURLWin32(url) {
	var hostname = url.hostname;
	var pathname = url.pathname;
	for (var n = 0; n < pathname.length; n++) {
	if (pathname[n] === '%') {
	var third = pathname.codePointAt(n + 2) | 0x20;
	if ((pathname[n + 1] === '2' && third === 102) || // 2f 2F /
	(pathname[n + 1] === '5' && third === 99)) { // 5c 5C \
	throw new ERR_INVALID_FILE_URL_PATH(
	'must not include encoded \\ or / characters'
	);
	}
	}
	}
	pathname = decodeURIComponent(pathname);
	if (hostname !== '') {
	// If hostname is set, then we have a UNC path
	// Pass the hostname through domainToUnicode just in case
	// it is an IDN using punycode encoding. We do not need to worry
	// about percent encoding because the URL parser will have
	// already taken care of that for us. Note that this only
	// causes IDNs with an appropriate `xn--` prefix to be decoded.
	return `//${domainToUnicode(hostname)}${pathname}`;
	} else {
	// Otherwise, it's a local path that requires a drive letter
	var letter = pathname.codePointAt(1) | 0x20;
	var sep = pathname[2];
	if (letter < CHAR_LOWERCASE_A || letter > CHAR_LOWERCASE_Z || // a..z A..Z
	(sep !== ':')) {
	throw new ERR_INVALID_FILE_URL_PATH('must be absolute');
	}
	return pathname.slice(1);
	}
	}
	function getPathFromURLPosix(url) {
	if (url.hostname !== '') {
	throw new ERR_INVALID_FILE_URL_HOST(platform);
	}
	var pathname = url.pathname;
	for (var n = 0; n < pathname.length; n++) {
	if (pathname[n] === '%') {
	var third = pathname.codePointAt(n + 2) | 0x20;
	if (pathname[n + 1] === '2' && third === 102) {
	throw new ERR_INVALID_FILE_URL_PATH(
	'must not include encoded / characters'
	);
	}
	}
	}
	return decodeURIComponent(pathname);
	}

[neroux]

@TimothyGu Good points, I guess I focused too much on the provided example :)
Thanks.

targos' URL solution does sound like the right approach in that case.