Giter Site home page Giter Site logo

node-app-root-path's Issues

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?

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.

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.

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`.

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.

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.

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.

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

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)

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).

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.

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

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.

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?

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?

wrongful access

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

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.

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" ]
  | }
  | }
  | }
  | }
  | }
  | }

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

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.

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?

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 1.0.0

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

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?

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)
    ```

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

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.

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.

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.