postinstall "cannot run in wd" when working directory does not match the package name (in docker) about npm-lifecycle HOT 3 OPEN

I also observed this (in action prepare for me, but whatever), in a Docker in a CI pipeline. Like @amadsen I’m not sure what ckeck the conditions around wd, opts.dir, and pkg.name: I observe they are always true, but possibly it is for a specific use case we don’t use.

Note that it is very common in Docker and specifically in CI to execute as root. I think it is a bad practice, but it is very common, even in the official Docker image for node (see this issue).

About npm-lifecycle, I wonder if there is not a logic bug around unsafe-perm+user+group:

• if unsafe-perm is false (as a root user with default unsafe-perm = false), there is no chance we execute the program because of the condition mentionned above lines 86-90,
• if unsafe-perm is true (as a non-root user or a root user with explicit unsafe-perm=true), we continue through the functions lifecycle_ then runPackageLifecycle/runHookLifecycle then runCmd and here we use the config values user and group only if unsafe-perm is false, but it is true in this branch, hence we always run the program as root and user/group are never used (at least in this branch path, perhaps it is used elsewhere).

from npm-lifecycle.

PS: if like me the action is in a child npm process (like in a dependency defined by a Git repo), the --unsafe-perm in the main npm was not enough (=not transmitted to the child npm), so it can be used an environment variable npm_config_unsafe_perm="true".

from npm-lifecycle.

@amadsen Thank you so much for digging into this! I’m adding this weird workaround to my package.json:

+  "__comment": "'name' must match the WORKDIR in Dockerfile used when executing `RUN npm ci`.",
+  "name": "app",

Also, if I understand _incorrectWorkingDirectory correctly it just does a convoluted “ends with” check. I guess the intention is to check that for example my-package matches /some/path/my-package but /some/path/foobar-my-package will match as well?

from npm-lifecycle.