You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 13, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 13, 2024. It is now read-only.
Error: Command failed: Executing pkg cli from the child process of pkg cli getting failed. #897
We have a requirement to call the shell script from pkg CLI and that script is again calling the same pkg CLI.
Our CLI is calling the shell script using the child_process package of the node. In a shell script, we are again calling the Pkg CLI if some condition is met.
Following is the testing Code: test.js
const doSomething1 = () => {
const childProcess = require('child_process');
console.log('Do Something 1 called');
// calling some shell script. and in script we have some condition if it is true then call doSomething2 from executables.
childProcess.execSync('./pkgBinary 2');
}
const doSomething2 = () => {
console.log('Do Somthing 2 called');
}
if (process.argv[2] === '1') {
doSomething1();
} else {
doSomething2();
}
Created binary using
pkg test.js -t 'node12-macos-x64' -o 'pkgBinary'
after the execution of command './pkgBinary 1'. I am getting the following error.
Error: Cannot find module '/Users/appirio-13532/practice/2'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:980:15)
at Function.Module._resolveFilename (pkg/prelude/bootstrap.js:1346:46)
at Function.Module._load (internal/modules/cjs/loader.js:862:27)
at Function.Module.runMain (pkg/prelude/bootstrap.js:1375:12)
at internal/main/run_main_module.js:18:47 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}
at checkExecSyncError (child_process.js:630:11)
at Object.execSync (child_process.js:666:15)
at Object.childProcess.execSync (pkg/prelude/bootstrap.js:1507:30)
at doSomething1 (/snapshot/practice/test.js)
at Object.<anonymous> (/snapshot/practice/test.js)
at Module._compile (pkg/prelude/bootstrap.js:1320:22)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1176:10)
at Module.load (internal/modules/cjs/loader.js:1000:32)
at Function.Module._load (internal/modules/cjs/loader.js:899:14)
at Function.Module.runMain (pkg/prelude/bootstrap.js:1375:12) {
Having exactly the same issue (same stack trace); @igorklopov what are you suggesting? If I want my pkg'd app to spawn an instance of itself, how should it be done?
I've tried these and they both throw MODULE_NOT_FOUND looking for arg1:
I had the same issue, and find some interesting behavior that is not documented for pkg - when you calling packed executable from outside, manually, it acts like if you call node with second argument set to internal main script ( /snapshot/project/main.js ). You can check it with console.log(process.argv) in "main.js", but you can't override it, like if it was a js function with binded first argument. But if you trying to spawn same executable recursively ( from inside that executable ), it will not be provided with second argument, which must be path to js file. so you can pass as a second argument another js file, which is responsible for your second logic branch. I create an example repo for OpenTerm I wrote, which is use same technique that i describe. - https://github.com/AndoGhevian/VT-pkg
This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label
diff --git a/node_modules/pkg/prelude/bootstrap.js b/node_modules/pkg/prelude/bootstrap.js
index 7285b7c..27d3975 100644
--- a/node_modules/pkg/prelude/bootstrap.js
+++ b/node_modules/pkg/prelude/bootstrap.js
@@ -1870,7 +1870,7 @@ function payloadFileSync(pointer) {
}
const opts = args[pos];
if (!opts.env) opts.env = _extend({}, process.env);
- if (opts.env.PKG_EXECPATH === 'PKG_INVOKE_NODEJS') return;
+ if (opts.env.PKG_EXECPATH !== undefined) return;
opts.env.PKG_EXECPATH = EXECPATH;
}
And setting PKG_EXECPATH: "" when creating child processes that might call the pkg'd executable (in our case, generally some user script that calls the garden binary). It's not very pretty, and requires us to remember this where we run child processes that might call the binary, but it does work for us.
It looks like pkg is explicitly monkey–patching the child_process functions to inject/overwrite the PKG_EXECPATH environment variable; that's half of the issue. The other half is acting differently when that environment variable is set; see #1565.
This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label
There are basically two camps of users. One camp wants a pkg-generated executable to behave as the bundled application in all scenarios. The other camp wants the executable to behave as the Node.js runtime when they want it to.
It is very tricky to support both cases, and I am considering to declare that "the pkg-generated executable can't be used as Node.js runtime" in the next major release.
This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label
So, in my understanding, it seems that this logic (where I am seeing the problem) is only true when we call the binary from the same binary using the child_process functions:
But if I comment the above logic (that is a very similar approach @edvald mentioned here) it starts to work.
in which other case is the above logic called? this is to understand if the validation could be improved in some way or what could I lose if I comment that logic just for my case. @jesec@robertsLando
Activity
igorklopov commentedon May 10, 2020
As a first step towards solving your issue, please switch to using
spawn/spawnSyncandprocess.execPathbecause it is tested to work this way https://github.com/zeit/pkg/blob/64c40421396fdeaa3607037731962f7fca5365c3/prelude/bootstrap.js#L1451.krische commentedon May 15, 2020
Have you had any luck with this issue? I think I am running into the same problem.
stripedpajamas commentedon May 27, 2020
Having exactly the same issue (same stack trace); @igorklopov what are you suggesting? If I want my pkg'd app to
spawnan instance of itself, how should it be done?I've tried these and they both throw
MODULE_NOT_FOUNDlooking forarg1:I've been able to solve my specific use-case by spawning a local module within my package where I've put the functionality:
But the main issue remains; I think I should be able to spawn the app itself with args. Is this supported?
eGavr commentedon Jul 31, 2020
I am running into the same problem, any news?
AndoGhevian commentedon Aug 24, 2020
I had the same issue, and find some interesting behavior that is not documented for pkg - when you calling packed executable from outside, manually, it acts like if you call node with second argument set to internal main script ( /snapshot/project/main.js ). You can check it with
console.log(process.argv)in "main.js", but you can't override it, like if it was a js function with binded first argument. But if you trying to spawn same executable recursively ( from inside that executable ), it will not be provided with second argument, which must be path to js file. so you can pass as a second argument another js file, which is responsible for your second logic branch. I create an example repo for OpenTerm I wrote, which is use same technique that i describe. - https://github.com/AndoGhevian/VT-pkggithub-actions commentedon Mar 25, 2021
This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label
github-actions commentedon Mar 31, 2021
This issue is now closed due to inactivity, you can of course reopen or reference this issue if you see fit.
zkochan commentedon May 14, 2021
I don't think this issue is solved. I am trying to bundle pnpm with pkg and getting this errors when there are
pnpm runcommands in lifecycle scripts.fix issue vercel#897
eysi09 commentedon May 26, 2021
Just chiming to say we're seeing the same issue in a tool we're building. Here's the relevant bug report.
Has anyone found a workaround to this?
zkochan commentedon May 26, 2021
I did this fork for pnpm with a few changes: https://github.com/zoli-forks/pkg
It seems to work fine for us.
24 remaining items
edvald commentedon Feb 24, 2022
FYI, the way we've solved this for ourselves is this patch, applied with https://www.npmjs.com/package/patch-package:
And setting
PKG_EXECPATH: ""when creating child processes that might call the pkg'd executable (in our case, generally some user script that calls thegardenbinary). It's not very pretty, and requires us to remember this where we run child processes that might call the binary, but it does work for us.feat: add an option for turning off Node.js hijacking
0x2b3bfa0 commentedon Mar 24, 2022
It looks like
pkgis explicitly monkey–patching thechild_processfunctions to inject/overwrite thePKG_EXECPATHenvironment variable; that's half of the issue. The other half is acting differently when that environment variable is set; see #1565.pkg/prelude/bootstrap.js
Lines 1851 to 1980 in 2ef4cd9
pkg/prelude/bootstrap.js
Line 1874 in 2ef4cd9
github-actions commentedon Jun 23, 2022
This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label
dacbd commentedon Jun 23, 2022
bump
feat: add an option for turning off Node.js hijacking
jesec commentedon Jul 5, 2022
There are basically two camps of users. One camp wants a pkg-generated executable to behave as the bundled application in all scenarios. The other camp wants the executable to behave as the Node.js runtime when they want it to.
It is very tricky to support both cases, and I am considering to declare that "the pkg-generated executable can't be used as Node.js runtime" in the next major release.
github-actions commentedon Oct 4, 2022
This issue is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this issue entirely you can add the no-stale label
github-actions commentedon Oct 10, 2022
This issue is now closed due to inactivity, you can of course reopen or reference this issue if you see fit.
koraniar commentedon Aug 2, 2023
Hello, I am having this same issue
I see in the code that the variable
PKG_EXECPATHis only filled here where we patch thechild_processfunctions:pkg/prelude/bootstrap.js
Line 2010 in bb04269
So, in my understanding, it seems that this logic (where I am seeing the problem) is only true when we call the binary from the same binary using the
child_processfunctions:pkg/prelude/bootstrap.js
Lines 77 to 84 in bb04269
But if I comment the above logic (that is a very similar approach @edvald mentioned here) it starts to work.
in which other case is the above logic called? this is to understand if the validation could be improved in some way or what could I lose if I comment that logic just for my case.
@jesec @robertsLando
Avivbens commentedon Sep 25, 2023
Hi all 👋
Any update about this one?
I see @koraniar in on to something, but still there is no PR for a fix 🥲