inxilpro/node-app-root-path

Determine the root path to your project

App Root Path Module

Please Note: Due to the very limited scope of this module, I do not anticipate needing to make very many changes to it. Expect long stretches of zero updates—that does not mean that the module is outdated.

This simple module helps you access your application's root path from anywhere in the application without resorting to relative paths like require("../../path").

Installation

$ npm i -S app-root-path

Usage

To simply access the app's root path, use the module as though it were a string:

var appRoot = require('app-root-path');
var myModule = require(appRoot + '/lib/my-module.js');

Side note: the module actually returns an object, but that object implements the toString method, so you can use it as though it were a string. There are a few edge cases where this might not be the case (most notably console.log), but they shouldn't affect actual use of the module, where you're almost always concatenating with an additional string.

A helper function is also provided:

var reqlib = require('app-root-path').require;
var myModule = reqlib('/lib/my-module.js');

It's a little hacky, but you can also put this method on your application's global object to use it everywhere in your project:

// In app.js
global.reqlib = require('app-root-path').require;

// In lib/module/component/subcomponent.js
var myModule = reqlib('/lib/my-module.js');

Finally, you can also just resolve a module path:

var myModulePath = require('app-root-path').resolve('/lib/my-module.js');

You can explicitly set the path, using the environmental variable APP_ROOT_PATH or by calling require('app-root-path').setPath('/my/app/is/here')

How It Works (under the hood)

No need to read this unless you're curious—or you run into a (very unlikely) case where the module does not work as expected.

This module uses two different methods to determine the app's root path, depending on the circumstances.

Primary Method

If the module is located inside your project's directory, somewhere within the node_modules directory (whether directly, or inside a submodule), we effectively do (the actual code takes cross-platform path names/etc into consideration):

path.resolve(__dirname).split('/node_modules')[0];

This will take a path like /var/www/node_modules/submodule/node_modules/app-root-path and return /var/www. In nearly all cases, this is just what you need.

Secondary Method (for edge cases)

The node module loader will also look in a few other places for modules (for example, ones that you install globally with npm install -g). These can be in one of:

• $HOME/.node_modules
• $HOME/.node_libraries
• $PREFIX/lib/node

Or, anywhere in the NODE_PATH environmental variable (see documentation).

In these cases, we fall back to an alternate trick:

path.dirname(require.main.filename);

When a file is run directly from Node, require.main is set to that file's module. Each module has a filename property that refers to the filename of that module, so by fetching the directory name for that file, we at least get the directory of file passed to node. In some cases (process managers and test suites, for example) this doesn't actually give the correct directory, though, so this method is only used as a fallback.

Edge-Case: Global CLIs

If your module is installed as a global CLI, for example in /usr/local/lib/node_modules/yourmodule, then require.main.filename will report /usr/local/lib/node_modules/yourmodule/bin, which is probably not what you want. app-root-path is aware of this edge-case and will strip the /bin automatically.

Change Log

3.1.0

• Added TypeScript types
• Added fallback for when require.main is missing (ESM imports)

3.0.0

• Improved Yarn Plug'n'Play support
• Fixed bug when used with webpack

2.2.1

• Better handling of webpack

2.2.0

• Added support for Yarn Plug'n'Play
• Adjusted browser-shim to address webpack warnings
• Bumped minimum Node version to 6

2.0.1

• Minor tweaks to how electron-specific logic runs. Should help with packagers that try to resolve all require() statements during packaging.

2.0.0

• Removed official support for node < 4.0
• Removed support for passing module.require to appRootPath.require (which has been deprecated for a while)
• Implemented semantic-release from here on out
• Added browserify-compatible shim

1.3.0

• Updated electron to match changes in version 1.0 of that project

1.2.1

• Had to bump package version because 1.2.0 got published to npm as @beta

1.2.0

• Special logic to resolve correctly when in an electron renderer process

1.1.0

• Special logic to handle an edge case when used in a globally-installed CLI project
• Fixed a bug where setPath() did not update require('app-root-path').path
• Moved some logic outside of the resolve() function so that it's not called multiple times

1.0.0

• No changes. Just updated the version to signify a locked API (see semver).

0.1.1

• Added Windows support (and, theoretically, other operating systems that have a directory separator that's not "/")

0.1.0

• Completely rewrote the path resolution method to account for most possible scenarios. This shouldn't cause and backwards compatibility issues, but always test your code.
• Removed the need to pass a modules's require() method to the appRootPath.require() function. Which it's true that each module has its own require() method, in practice it doesn't matter, and it's much simpler this way.
• Added tests

Development Nodes

When using semantic-release, the preferred method for commits is:

• git add …
• git cz (see commitizen)
• git push

This helps ensure that commits match the expected format. Commits to master will cause releases.

node-app-root-path's Issues

Main lib returns object, not path string

The docs should be updated to reflect that require('app-root-path') returns an object, not the path string. It should be .require('app-root-path').path.

https://github.com/inxilpro/node-app-root-path/blob/master/lib/app-root-path.js#L37

What constituted the bump in major version?

What constituted the breaking change in release 3.0.0?

Changes

Incorrect path when used within both project and its dependency on npm v3

Hello!

I have been using app-root-path for numerous projects and have found it reliable and helpful. However, my frequent use seems to now be catching up to me.

I have two projects - a module I have published and a web app - both of which are using app-root-path. The app loads first, requires app-root-path, and then later loads the module which again requires app-root-path. Because npm 3 is now deduping modules there is only one installation of app-root-path (inside my-web-app/node_modules), and these two projects then share a single handle. Thus, my module that the app depends on is erroneously determining that its app-root-path is within the web app, not within its module folder.

If the web app were not using app-root-path this would presumably not be a problem because app-root-path would initialize only when the module loads it.

This seems like a notable problem with app-root-path, unearthed by the deduping behavior of npm v3. Any ideas on a solution? The module's design seems to be such that it's caching paths and I am aware of no way to force npm to install it locally (no dedupe).

wrongful access

sorry for not knowing what i was clicking. i am new to this and am just now learning

Version 1.0.0

I'm mentioning all the current stargazers on this project for feedback:

• @demohi
• @kgryte
• @nwhite89
• @ruairitobrien
• @cabhishek
• @kjirou
• @Californian
• @epicbagel
• @ubercow
• @lxe

I feel like the app-root-path module is ready for the 1.0.0 designation: the module's API is finalized and there are no features that I can think of adding (this is a very simple plugin, so I don't expect ever adding much more).

Anyone feel like there's something that should be added or changed before I make it official?

app-root-path is using "module" node module which cause issue when using at client side

I am using Angularjs 1.x and commonjs and compiling using webpack. Since my compiled js file serve on browser therefore it has to be as small as possible.
I thought to use app-root-path module for my client side as well however i realized that it throws error in webpack compilation because "resolve.js" is doing require("module"). And when I installed "module" node package then it included big files and also throws error in browser console.

I am not expecting to solve this issue. However wanted to share that due to this issue i can't use it for client side module bundling.

Path resolution in npm linked modules report module and not root app path.

I only noticed this today when changes in globby starting throwing path errors, so might have been there a while and I just didn't notice.

Under node v11, working in an app with the following pattern:

./project/app/
./project/shared-lib-1/
./project/shared-lib-2/

app-root-path is used in each shared lib. When these are installed with npm install, the libs correctly report the app's root path. In development, when the libs are linked with npm link, app-root-path reports the root path of the lib module, not the app.

node_modules isn't cool anymore, what to do

I just read about yarn's new plug n play install and it looks like npm might be pursuing something similar.

Since one of the main heuristics used here is the presence of node_modules, I could see this breaking if these new module resolution systems gain traction.

Include node installs via nvm as edge case

The edge cases don't account for nvm installations of node. When globally installing modules in this case, it can lead to incorrect paths being collected and issues such as this:

/Users/{user}/.nvm/versions/node/v6.9.5/lib/node_modules/{pkg}/src/state did not exist, creating...
Successfully wrote file to /Users/{user}/.nvm/versions/node/v6.9.5/lib/node_modules/{pkg}/src/state/App/index.js

Version 2.1.0 Broken

No longer works correctly inside docker container (using amazon linux)

It now points to /var/task/ instead of correct folder (was /user/project/)

Let me know if you need help reproducing.

Always resolves to module root

I am probably mis-understanding the goal of this application, but here's what I'm trying to do:

I have an express project, call it ExpressExample. I have a module called MyModule which I've installed or linked into ExpressExample. Therefore the module's code is at ExpressExample/node_modules/MyModule. However, it's very possible that the module could be installed as ExpressExample/node_modules/SomeModule/node_modules/MyModule.

I'd like to access a file in the ExpressExample folder. I was hoping that I could use:

var appRoot = require('app-root-path');
appRoot.path

to access the ExpressApp folder. Instead I get the MyModule folder. On my computer, when I make local modules, I install them with the npm link command which means they may not even be in a subdirectory of the project. For example, I may have my code in ~/developer/apps/ExpressApp and ~/developer/modules/MyModule. When I use appRoot.path I get the actual fs path '/developer/modules/MyModule, not the path where the module lives in the project:/developer/apps/ExpressApp/node_modules/MyModule`.

npm package.json version != github repo version

Hi there,

Is there any chance you could bump the package.json version to 2.1.0 so that it matches what is published to npmjs?

I'm trying to get this package approved for use at work. They're pretty strict about licensing and want to link the package publish date back to some commit in the source repo.

The problem here is that version 2.1.0 is what we are grabbing from npm and the publish date of that matches the last commit in the repository, however the version in package.json in this repo indicates 2.0.1.

Basically since there is a mismatch between the source repository and the package contents it is causing issues :(

Many thanks

Issues

Support for yarn workspaces

Hey,

Currently the package is not compatible with yarn workspaces/lerna.
Example of issue you can find here: typeorm/typeorm#2805

Is there any way to support yarn workspaces/lerna for monorepo solutions?

Regards,
TheAifam5

Androidapk merge

• [ ]

• @[angle_extract_native_libs]

Import("//build/config/android/rules.gni")

  | import("../gni/angle.gni")
  |  
  | vulkan_validation_layers = [ "VkLayer_khronos_validation" ]
  |  
  | angle_libraries = [
  | "libEGL",
  | "libGLESv1_CM",
  | "libGLESv2",
  | "libfeature_support",
  | ]
  |  
  | if (enable_java_templates) {
  | template("angle_apk") {
  | manifest_target_name = "${target_name}__manifest"
  | manifest_path =
  | "${target_gen_dir}/${target_name}/android/AndroidManifest.xml"
  |  
  | jinja_template(manifest_target_name) {
  | input = "//third_party/angle/android/AndroidManifest.xml.jinja2"
  | output = manifest_path
  | variables = [
  | "manifest_package=${invoker.package_name}",
  | "extract_native_libs=${angle_extract_native_libs}",
  | ]
  | }
  |  
  | android_assets("${invoker.package_name}_assets") {
  | disable_compression = true
  | sources = [
  | "src/feature_support_util/a4a_rules.json",
  | ]
  | }
  |  
  | android_apk(target_name) {
  | forward_variables_from(invoker, "*")
  | android_manifest = manifest_path
  | android_manifest_dep = ":$manifest_target_name"
  | min_sdk_version = 26
  | target_sdk_version = 28
  | deps = [
  | ":${invoker.package_name}_assets",
  | ]
  | if (symbol_level != 0) {
  | deps += [ ":compressed_symbols" ]
  | if (android_64bit_target_cpu) {
  | deps += [ ":compressed_symbols($android_secondary_abi_toolchain)" ]
  | }
  | }
  |  
  | uncompress_shared_libraries = true
  |  
  | if (android_64bit_target_cpu) {
  | if (symbol_level == 0) {
  | secondary_abi_shared_libraries = []
  | foreach(_library, angle_libraries) {
  | secondary_abi_shared_libraries +=
  | [ "$angle_root:${_library}($android_secondary_abi_toolchain)" ]
  | }
  | if (angle_enable_vulkan_validation_layers) {
  | foreach(_layer, vulkan_validation_layers) {
  | secondary_abi_shared_libraries += [
  | "$angle_root/third_party/vulkan-validation-layers:${_layer}" +
  | "($android_secondary_abi_toolchain)",
  | ]
  | }
  | }
  | } else {
  | _secondary_out_dir = get_label_info(
  | ":compressed_symbols($android_secondary_abi_toolchain)",
  | "root_out_dir")
  | secondary_abi_loadable_modules = []
  | foreach(_library, angle_libraries) {
  | secondary_abi_loadable_modules += [ "$_secondary_out_dir/lib.compressed/${_library}${angle_libs_suffix}.so" ]
  | }
  | if (angle_enable_vulkan_validation_layers) {
  | foreach(_layer, vulkan_validation_layers) {
  | secondary_abi_loadable_modules +=
  | [ "${_secondary_out_dir}/lib.compressed/lib${_layer}.so" ]
  | }
  | }
  | }
  | }
  |  
  | if (symbol_level == 0) {
  | shared_libraries = []
  | foreach(_library, angle_libraries) {
  | shared_libraries += [ "$angle_root:$_library" ]
  | }
  | if (angle_enable_vulkan_validation_layers) {
  | foreach(_layer, vulkan_validation_layers) {
  | shared_libraries +=
  | [ "$angle_root/third_party/vulkan-validation-layers:${_layer}" ]
  | }
  | }
  | } else {
  | loadable_modules = []
  | foreach(_library, angle_libraries) {
  | loadable_modules += [
  | "$root_out_dir/lib.compressed/${_library}${angle_libs_suffix}.so",
  | ]
  | }
  | if (angle_enable_vulkan_validation_layers) {
  | foreach(_layer, vulkan_validation_layers) {
  | loadable_modules +=
  | [ "$root_out_dir/lib.compressed/lib${_layer}.so" ]
  | }
  | }
  | }
  | }
  | }
  | }

Mistenken added issue

Issues

Not working in modules required by other modules

I'm not sure how else to make this suggestion, but couldn't you check that the parent of the parent of whatever node_modules directory you find isn't node_modules and, if it is, recursively continue up the folders until you get to a folder whose parent isn't node_modules? If you don't see any flaws in my logic, I can modify and make a pull request.

Version number mismatch on github and npm directory

The npm directory still lists version 1.0.0 as the latest version while your package.json claims the package is on 1.2.0.

Did you miss to run npm publish after updating the version? Would really appreciate an update, since it causes minor version mismatches in my project.

Thanks for this, anyway!

Auto including index.js

With node's require, when you specify a path of a folder, if there an index.js file, require automatically picks up the index.js file.

Is that not the case with this module? Do i have to specify index.js explicitly?

Not returning the correct app path on AWS Lambda

Fix it please. It wasted 2 days of my time.

Incompatible with Browserify

Browserify 16.5.0 does not seem to provide a .main property on the require object, so requiring app-root-path is failing because browser cannot read property .filename from require.main (which is undefined)

node-app-root-path/browser-shim.js

Line 3 in 54d06fe

exports.path = require('path').dirname(require.main.filename);

#22 seems to be related to the same problem, but was closed without any more information about why.

You can reproduce breaking browserify with:

echo "console.log(require('app-root-path').toString())" > test.js
browserify test.js -o bundle.js

and then trying to load bundle.js with a script tag in a browser.

Browser Shim Error

app-root-path throws an error when I try to use it with Browserify:

Uncaught TypeError: Cannot read property 'filename' of undefined
    at Object.require.48.path (browser-shim.js:3)
    at s (_prelude.js:1)
    at _prelude.js:1
    at Object.require.13.Vendor (product.js:9)
    at s (_prelude.js:1)
    at _prelude.js:1
    at Object.require.379.Vendor (product.js:16)
    at s (_prelude.js:1)
    at e (_prelude.js:1)
    at _prelude.js:1

Might this be related to customizing the Browserify paths option?

Package throws an error when imported in an ES module installed globally on Ubuntu

The error is:

/usr/local/lib/node_modules/app-root-path-ubuntu-repro/node_modules/app-root-path/lib/resolve.js:111
		appRootPath = path.dirname(requireFunction.main.filename);
		                                                ^

TypeError: Cannot read properties of undefined (reading 'filename')
    at resolve (/usr/local/lib/node_modules/spellchecker-cli/node_modules/app-root-path/lib/resolve.js:111:51)
    at module.exports (/usr/local/lib/node_modules/spellchecker-cli/node_modules/app-root-path/lib/app-root-path.js:6:20)
    at Object.<anonymous> (/usr/local/lib/node_modules/spellchecker-cli/node_modules/app-root-path/index.js:4:18)
    at Module._compile (node:internal/modules/cjs/loader:1105:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:170:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:198:25)
    at async Promise.all (index 0)

I've created a repo that you can use to reproduce this error: https://github.com/tbroadley/app-root-path-ubuntu-repro

I think the issue is that app-root-path assumes that requireFunction.main is always defined. However, according to the Node.js documentation:

When the entry point is not a CommonJS module, require.main is undefined, and the main module is out of reach.

Incorrect root path for app globally installed on Mac

Using @olsonpm's https://github.com/olsonpm/exampleCLI

I've changed the version of app-root-path to 2.1.0

$ npm install -g exampleCLI-0.1.0.tgz
$ examplecli
root
{ resolve: [Function: resolve],
  require: [Function: require],
  toString: [Function: toString],
  setPath: [Function: setPath],
  path: '/usr/local/lib' }

root.toString()
/usr/local/lib

I expected path to be /usr/local/lib/node_modules/exampleCLI

I notice that the path is a bit different than in #8 , I assume node's default location for global packages has changed since then?

I also checked require('module').globalPaths:

[ '/Users/user-name/.node_modules',
  '/Users/user-name/.node_libraries',
  '/usr/local/Cellar/node/10.7.0/lib/node' ]

and /usr/local/lib/node_modules doesn't appear, could that be throwing things off?

Webpack warning: Critical dependency: the request of a dependency is an expression

webpack/webpack#196

in ./node_modules/app-root-path/browser-shim.js
Critical dependency: the request of a dependency is an expression

It's not a catastrophic error but it is pretty unfortunate having to filter this error in all of my webpack projects that use it.

New version broke webpack build with TypeORM

Commit b20b622 broke TypeORM webpack project. (I think it is not TypeORM specific).

I'm using webpack to build my node/typescript project, I am not using yarn at all.

Module not found: Error: Can't resolve 'pnpapi' in 'project\node_modules\app-root-path\lib'
 @ ./node_modules/app-root-path/lib/resolve.js 30:12-29
 @ ./node_modules/app-root-path/lib/app-root-path.js
 @ ./node_modules/app-root-path/index.js
 @ ./node_modules/typeorm/platform/PlatformTools.js
 @ ./node_modules/typeorm/driver/mongodb/typings.js
 @ ./node_modules/typeorm/index.js
 @ ./src/engine/components/Database.ts
 @ ./src/engine/configuration/ComponentRegistry.ts
 @ ./src/engine/loaders/ComponentLoader.ts
 @ ./src/Engine.ts
 @ ./src/init.ts

The if (process.versions.pnp) {...} should not activate.

`.npmignore` does not include `.idea/` or `.nyc_output`.

So those are included in the version on NPM.

Incorrect root path when using with cli libraries

Example repository which exhibits the behavior

https://github.com/olsonpm/exampleCLI

$ npm install --save -g "olsonpm/exampleCLI"
... # let it install
$ exampleCLI
# outputs
root
{ resolve: [Function],
  require: [Function],
  toString: [Function],
  setPath: [Function],
  path: '/home/<username>/.nvm/v0.10.36/lib/node_modules/exampleCLI/bin' }

root.toString()
/home/<username>/.nvm/v0.10.36/lib/node_modules/exampleCLI/bin

Now based on the readme (and without digging into your code), I couldn't tell if it should be reporting
/home//.nvm/v0.10.36/lib
or
/home//.nvm/v0.10.36/lib/node_modules/exampleCLI

however I didn't expect it to report the bin directory

require('remote'); breaks javascript packers

It is not possible anymore to use app-rooth-path with javascript packers (browserify for example) because of hidden dependency to electron internals:

// Defer to main process in electron
if ('type' in process && 'renderer' === process.type) {
        var remote = require('remote');
        return remote.require('app-root-path').path;
}

This is what I got when using nexe (which uses browserify internally)

Error: Cannot find module 'remote' from '.......\node_modules\app-root-path\lib'

My workaround for the moment is to stick with version 1.0.0 but it will be a pity in long term to do it.

Rest resolve parameter.

If rest appRootPath.resolve params and join with path.sep will be great.

var appRootPath = require('app-roo-path');
var barDirPath = appRootPath.resolve('foo', 'bar'); //  root/foo/bar

Google Cloud Functions reports incorrect path

When deploying servererless insto Google Cloud functions - the app root reported is incorrect.

const appRoot = require("app-root-path");
console.log(appRoot.toString());

/layers/google.nodejs.functions-framework/functions-framework/node_modules/@google-cloud/functions-framework/build/src

console.log(__dirname);

/workspace

I'm not sure where to look to see what could be causing this, if I get time I will see what's going on and create a PR.

Wrong app root path on Windows with scoped packages and nvm

I have globally installed a Node.js application on Windows, where Node.js was installed using nvm-windows. This works.

What's unusual about my scenario is that the module is a scoped one, i.e. there is an @org prefix in its name, which results in an additional directory. So the path looks like this:

C:\Users\jane.doe\AppData\Roaming\nvm\v6.7.0\node_modules\@org\my-app

This is the application's root path. Now inside of this application I am using a module. It gets installed to the application's node_modules directory, so we end up with:

C:\Users\jane.doe\AppData\Roaming\nvm\v6.7.0\node_modules\@org\my-app\node_modules/my-module

Now, this module uses app-root-path to get the root path of the application.

The expected result is:

C:\Users\jane.doe\AppData\Roaming\nvm\v6.7.0\node_modules\@org\my-app

The actual result is:

C:\Users\jane.doe\AppData\Roaming\nvm\v6.7.0

Obviously app-root-path detects the root path in a wrong way, but I am not sure why. It may be that it is because of the additional node_modules directory (which, I guess, is caused by nvm on Windows), or it may be because the application is a scoped packages.

Unfortunately, as I am not really sure about the cause, I can not provide a fix. Any ideas on this?

npm published version != package.json version

There is an issue with the current published version of app-root-path.

my package.json contains

"dependencies": {
    "app-root-path": "^1.0.0"
}

but if i run npm outdated I get

Package        Current  Wanted  Latest
app-root-path    1.0.0   1.2.0   1.0.0

if 1.2.0 is a beta that it should have been published as 1.2.0-beta

Library is not returning the application path for Webapp hosted on Azure.

Hosted a node application on Azure as Web App which is using app-root-path library to resolve the file paths. It is resolving to iisnode directory which is the node handler for IIS (D:\Program Files\iisnode) whereas application is hosted in different folder, i.e. D:\home\site\wwwroot.

Steps to reproduce -

1. Create a web app on Azure using App Service template.
2. Print application path using console.log(require('app-root-path').path)

Latest NPM release failed (3.0.0)

See https://travis-ci.org/inxilpro/node-app-root-path/jobs/603906785#L345

PNPM support?

The resolution with pnpm https://github.com/pnpm/pnpm seems not to work as expected.

My setup is a nestjs project with typeorm.

The resulting app root path is under .../project/dist which is the build path of a nestjs project but not the root.

From my investigations i see the error happens here: https://github.com/inxilpro/node-app-root-path/blob/master/lib/resolve.js#L64

Because pnpm fills the global path with multiple entries like:

  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/custom.npm.registry/@nestjs/cli/6.11.0/node_modules/@nestjs/cli/bin/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/custom.npm.registry/@nestjs/cli/6.11.0/node_modules/@nestjs/cli/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/custom.npm.registry/@nestjs/cli/6.11.0/node_modules/@nestjs/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/custom.npm.registry/@nestjs/cli/6.11.0/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/custom.npm.registry/@nestjs/cli/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/custom.npm.registry/@nestjs/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/custom.npm.registry/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules/.pnpm/node_modules',
  '/Users/user/projects/tmp/test-orm/node_modules',

And then the check for global matches even if it is not a global thing. For my case the solutions here: https://github.com/inxilpro/node-app-root-path/blob/master/lib/resolve.js#L74 would bring the desired effect.

How would I use this in ES6 syntax (import)?

I like const reqlib = require('app-root-path').require; but I would love to use this with import. How would I go about doing this?

Need Yarn 2 monorepo support

Current resolver detects Yarn Plug 'N' Play but resolves app root path to repo root, but in the context of a monorepo structure, it may be desirable to have app root resolve to the workspace root.

I am no Yarn 2 API expert, but it seems findPackageLocator() or some such function might be useful.

ReferenceError: __dirname is not defined in ES module scope

I try using the lib in my project to fix Windows builds via GitHub actions. Otherwise my projects build fine.

Seems like the lib isn't compatible with ES modules setup...

Here's the repo https://github.com/davay42/vitepress-pages

ReferenceError: __dirname is not defined in ES module scope
    at node_modules/.pnpm/[email protected]/node_modules/app-root-path/index.js (file:///Users/davay/Documents/%D0%A4%D0%A0%D0%A3%D0%9A%D0%A2/Chromatone/chromatone.center/node_modules/.pnpm/[email protected][email protected]/node_modules/vitepress-pages/dist/index.js:129:26)
    at __require2 (file:///Users/davay/Documents/%D0%A4%D0%A0%D0%A3%D0%9A%D0%A2/Chromatone/chromatone.center/node_modules/.pnpm/[email protected][email protected]/node_modules/vitepress-pages/dist/chunk-2LGAEF77.js:15:50)
    at file:///Users/davay/Documents/%D0%A4%D0%A0%D0%A3%D0%9A%D0%A2/Chromatone/chromatone.center/node_modules/.pnpm/[email protected][email protected]/node_modules/vitepress-pages/dist/index.js:138:36
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:541:24)
    at async loadConfigFromBundledFile (file:///Users/davay/Documents/%D0%A4%D0%A0%D0%A3%D0%9A%D0%A2/Chromatone/chromatone.center/node_modules/.pnpm/[email protected]/node_modules/vite/dist/node/chunks/dep-5e7f419b.js:62084:21)
    at async loadConfigFromFile (file:///Users/davay/Documents/%D0%A4%D0%A0%D0%A3%D0%9A%D0%A2/Chromatone/chromatone.center/node_modules/.pnpm/[email protected]/node_modules/vite/dist/node/chunks/dep-5e7f419b.js:61969:28)
    at async resolveConfig (file:///Users/davay/Documents/%D0%A4%D0%A0%D0%A3%D0%9A%D0%A2/Chromatone/chromatone.center/node_modules/.pnpm/[email protected]/node_modules/vite/dist/node/chunks/dep-5e7f419b.js:61590:28)
    at async doBuild (file:///Users/davay/Documents/%D0%A4%D0%A0%D0%A3%D0%9A%D0%A2/Chromatone/chromatone.center/node_modules/.pnpm/[email protected]/node_modules/vite/dist/node/chunks/dep-5e7f419b.js:44358:20)
    ```