Closed lokrajahuja closed 1 year ago
As a first step towards solving your issue, please switch to using spawn
/spawnSync
and process.execPath
because it is tested to work this way https://github.com/zeit/pkg/blob/64c40421396fdeaa3607037731962f7fca5365c3/prelude/bootstrap.js#L1451.
Have you had any luck with this issue? I think I am running into the same problem.
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
:
spawn('myappname', ['arg1']) // Error: Cannot find module '/path/to/my/app/arg1'
spawn(process.execPath, ['arg1']) // Error: Cannot find module '/path/to/my/app/arg1'
I've been able to solve my specific use-case by spawning a local module within my package where I've put the functionality:
spawn(process.execPath, [require.resolve('./arg1-handler')])
But the main issue remains; I think I should be able to spawn the app itself with args. Is this supported?
I am running into the same problem, any news?
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
This issue is now closed due to inactivity, you can of course reopen or reference this issue if you see fit.
I don't think this issue is solved. I am trying to bundle pnpm with pkg and getting this errors when there are pnpm run
commands in lifecycle scripts.
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?
I did this fork for pnpm with a few changes: https://github.com/zoli-forks/pkg
It seems to work fine for us.
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
This issue is now closed due to inactivity, you can of course reopen or reference this issue if you see fit.
I don't think a bot should close an issue just because nobody prioritized it yet.
Due to this issue, I use a fork of vercel/pkg to release the pnpm CLI.
@zkochan Would you mind to submit a PR?
I also ran into this issue, but specifically because pkg
mutates child_process
calls, overwriting node
with its own execution path: https://github.com/vercel/pkg/blob/main/prelude/bootstrap.js#L1874-L1894 (specifically L1880). Our app needs to execute Node, not itself.
I consider global mutation bad behavior that introduces unexpected side-effects to userland. Is this absolutely necessary? Can we at least have an opt-out?
Happy to PR if you'd like to provide some guidance!
I think it could be opted out using an env var? @jesec
I'd be fine with an env var or cli flag, whatever works for y'all.
Just checking back again: would a PR be welcome?
I have an open pull request that fixes this issue: https://github.com/vercel/pkg/pull/1344
FYI, the way we've solved this for ourselves is this patch, applied with https://www.npmjs.com/package/patch-package:
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
bump
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
This issue is now closed due to inactivity, you can of course reopen or reference this issue if you see fit.
Hello, I am having this same issue
I see in the code that the variable PKG_EXECPATH
is only filled here where we patch the child_process
functions: https://github.com/vercel/pkg/blob/bb042694e4289a1cbc530d2938babe35ccc84a93/prelude/bootstrap.js#L2010
-
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:
https://github.com/vercel/pkg/blob/bb042694e4289a1cbc530d2938babe35ccc84a93/prelude/bootstrap.js#L77-L84
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
Hi all 👋
Any update about this one? I see @koraniar in on to something, but still there is no PR for a fix 🥲
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
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: Command failed: ./pkgBinary 2 internal/modules/cjs/loader.js:983 throw err; ^
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: [] }
status: 1, signal: null, output: [ null,