Feature Request: method for resolving the directory of a package

[kumavis]

What is the problem this feature will solve?

exposing node's module resolution algorithm to utilities

What is the feature you are proposing to solve the problem?

import { resolvePackageDirectory } from 'module';

const xyzDirectoryPath = resolvePackageDirectory('xyz', import.meta.url)
// "/project/node_modules/abc/node_modules/xyz/"

What alternatives have you considered?

the previous trick was

import { dirname } from 'path';
import { createRequire } from 'module';

const require = createRequire(import.meta.url);
// package.json was only reliable location
const packageJsonPath = require.resolve('xyz/package.json');
const xyzDirectoryPath = dirname(packageJsonPath);

but with the introduction of the exports specifier, there is no reliable way to resolve the package's location on disk

[kumavis]

resolvePackageDirectory can be async if preferred

[kumavis]

the internal readPackageScope can be used here

const require = createRequire(import.meta.url);
const rootExportPath = require.resolve('xyz'); // assuming root export
const xyzDirectoryPath = readPackageScope(rootExportPath).path // NOT exposed externally

node/lib/internal/modules/cjs/loader.js

Lines 321 to 336 in acc11c9

	function readPackageScope(checkPath) {
	const rootSeparatorIndex = StringPrototypeIndexOf(checkPath, sep);
	let separatorIndex;
	do {
	separatorIndex = StringPrototypeLastIndexOf(checkPath, sep);
	checkPath = StringPrototypeSlice(checkPath, 0, separatorIndex);
	if (StringPrototypeEndsWith(checkPath, sep + 'node_modules'))
	return false;
	const pjson = readPackage(checkPath + sep);
	if (pjson) return {
	data: pjson,
	path: checkPath,
	};
	} while (separatorIndex > rootSeparatorIndex);
	return false;
	}

[Trott]

@nodejs/modules

[devsnek]

what would resolvePackageDirectory do when the target is not a folder with a package.json

[devsnek]

also do exports actually stop you from resolving package.json files? that seems like an anti-feature.

[ljharb]

Duplicate of #49445 / #33460 ?

[ljharb]

Yes, exports does stop that. This api is one the modules group was on board to land, but never got built.

[GeoffreyBooth]

This is a duplicate of #49445 and also discussed in nodejs/loaders#26, but I guess it’s not really a duplicate if it’s in the node repo rather than the others? Dunno how we consider cross-repo duplicates. The plan is to address this as part of nodejs/loaders#26, and you can see an example implementation in the function getPackageType in https://nodejs.org/api/esm.html#transpiler-loader.

[ljharb]

Is there any reason addressing it needs to wait for loaders to land? There's many use cases for it that don't (and can't) involve loaders.

[aduh95]

@ljharb there's no reason to wait for loaders to land, the loaders team has plans to do it in the future but I don't think they would mind if someone else was pushing it forward (quite the contrary), you (or anyone else) are welcome to open a PR to add an API doing this; however such API would have to align with the loader use case – so we don't end up with several slightly different API that don't interop with one another.

[ljharb]

Great, as long as the reverse is also true - that anything loaders provides also handles the non-loader use cases.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[ljharb]

unstale

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[ljharb]

bump

[bnoordhuis]

This is basically a duplicate of nodejs/loaders#26, right? If so, I'm inclined to close this as inactionable / blocked-on / whatever and direct people to the loaders issue.

[GeoffreyBooth]

This is basically a duplicate of nodejs/loaders#26, right? If so, I’m inclined to close this as inactionable / blocked-on / whatever and direct people to the loaders issue.

I don’t know if we want to make issues in other repos canonical. We archive those other repos occasionally, and we wouldn’t want to lose batches of feature requests when we do so.

Yes this is duplicative, but only in the sense that the loaders issue is a proposal for an API to would do a bunch of things including satisfying this request.

[ljharb]

I don't see how a loader can satisfy this request, which is runtime resolution long after the program has begun.

[bnoordhuis]

It doesn't matter to me if it's this issue that stays open or the loaders one but having two issues (and discussions) for the same feature isn't great. I'll close this but feel free to reopen when the other issue is resolved/archived/etc.

To people coming here from search engines, please go here: nodejs/loaders#26