Google Cloud Functions reports incorrect path

[inxilpro]

Google Cloud Functions reports incorrect path

[sturtevant]

I just ran into this when it broke TypeORM config file resolution (app-root-path is a dependency of TypeORM). I think the reason it is breaking is that /workspace/node_modules is included in globalPaths. This bypasses the correct answer (/workspace) and drops down into the alternate resolution logic that produces the incorrect app root based on the value of require.main.filename.

In case it helps, here are some (sanitized) values from the runtime of my Google Cloud Function:

process.platform: "linux"

process.env: {
  "GCF_BLOCK_RUNTIME_nodejs6": "410",
  "NO_UPDATE_NOTIFIER": "true",
  "FUNCTION_TARGET": "main",
  "NODE_PATH": "/workspace/node_modules",
  "NODE_ENV": "production",
  "PWD": "/workspace",
  "HOME": "/root",
  "DEBIAN_FRONTEND": "noninteractive",
  "PORT": "8080",
  "SHLVL": "1",
  "GAE_RUNTIME": "nodejs14",
  "FUNCTION_SIGNATURE_TYPE": "http",
  "PATH": "/workspace/node_modules/.bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
  "_": "/layers/google.nodejs.functions-framework/functions-framework/node_modules/.bin/functions-framework"
}

process.versions: {
  "node": "14.16.0",
  "v8": "8.4.371.19-node.18",
  "uv": "1.40.0",
  "zlib": "1.2.11",
  "brotli": "1.0.9",
  "ares": "1.16.1",
  "modules": "83",
  "nghttp2": "1.41.0",
  "napi": "7",
  "llhttp": "2.1.3",
  "openssl": "1.1.1j",
  "cldr": "37.0",
  "icu": "67.1",
  "tz": "2020a",
  "unicode": "13.0"
}

require('module').globalPaths: [
  "/workspace/node_modules",
  "/root/.node_modules",
  "/root/.node_libraries",
  "/usr/lib/node"
]

require.main.filename: "/layers/google.nodejs.functions-framework/functions-framework/node_modules/@google-cloud/functions-framework/build/src/index.js"

Ultimately my workaround fix was to set the APP_ROOT_PATH environment variable in the Cloud Function to /workspace to get the correct behavior. This isn't very intuitive, however, and is likely to trip up a lot of folks who (like me) don't even realize that app-root-path is in their dependency chain.

Perhaps a short-circuit (similar to the one already in place for AWS Lambda) could be implemented to disregard the fact that /workspace/node_modules is in the globalPaths whenever the string '@google-cloud/functions-framework' was in the path of require.main.filename?

[Michaelp1994]

I seem to be running into the same issue trying to get TypeORM working with Serverless-Stack Live Lamda Development for AWS Lambda functions.
I get the following error:
ERROR Runtime.UnhandledPromiseRejection: TypeError: Cannot read properties of undefined (reading 'filename')
Not sure if it has to do with ESBuild being used.
@sturtevant your suggestion of setting APP_ROOT_PATH for the lambda environment seems to have hot-fixed the issue my issue as well.

[FFdhorkin]

I seem to be running into the same issue trying to get TypeORM working with Serverless-Stack Live Lamda Development for AWS Lambda functions. I get the following error: ERROR Runtime.UnhandledPromiseRejection: TypeError: Cannot read properties of undefined (reading 'filename') Not sure if it has to do with ESBuild being used. @sturtevant your suggestion of setting APP_ROOT_PATH for the lambda environment seems to have hot-fixed the issue my issue as well.

I'm having a similar issue with serverless-esbuild / serverless-offline...

• the resolved variable in app-root-path's resolve.js is resolving to '/my/path/to/project/.esbuild/.build/src'
• the appRootPath is being returned as '/my/path/to/project/node_modules/serverless-offline/src/lambda/handler-runner/worker-thread-runner'
• and what I want would be /my/path/to/project/

I have opened a PR (#55) to make esbuild play nice