I am using MacOS Sonoma and when I run intelephense --version on the command line. I get output consisting of 10's of thousands of lines of Node errors. I have tried uninstalling and reinstalled Intelephense globally via Yarn and NPM, including various versions of Node using nvm. The truncated error begins:

/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7
            })(name => super[name], (name, value) => super[name] = value);`}}});function FS(e){return 9===e.kind}function RS(e){return 10===e.kind}function FS(e){return 9===e.kind}function RS(e){return 10===e.kind}function PS(e){return 11===e.kind}function MS(e){return 12===e.kind}function LS(

and so on and so on for very long. It ends with:

Error: Connection input stream is not set. Use arguments of createConnection or set command line parameters: '--node-ipc', '--stdio' or '--socket={number}'
    at /opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:3792433
    at t.createConnection (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:3793598)
    at 26997 (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:2:2933803)
    at __webpack_require__ (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:4115664)
    at /opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:4116348
    at Object.<anonymous> (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:4116376)
    at Module._compile (node:internal/modules/cjs/loader:1739:14)
    at Object..js (node:internal/modules/cjs/loader:1904:10)
    at Module.load (node:internal/modules/cjs/loader:1473:32)
    at Function._load (node:internal/modules/cjs/loader:1285:12)

Node.js v23.6.0

It appears that the super long message is just the contents of intelephense.js? Any idea what is going on here?

I am using MacOS Sonoma and when I run intelephense --version on the command line. I get output consisting of 10's of thousands of lines of Node errors. I have tried uninstalling and reinstalled Intelephense globally via Yarn and NPM, including various versions of Node using nvm. The truncated error begins:

/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7
            })(name => super[name], (name, value) => super[name] = value);`}}});function FS(e){return 9===e.kind}function RS(e){return 10===e.kind}function FS(e){return 9===e.kind}function RS(e){return 10===e.kind}function PS(e){return 11===e.kind}function MS(e){return 12===e.kind}function LS(

and so on and so on for very long. It ends with:

Error: Connection input stream is not set. Use arguments of createConnection or set command line parameters: '--node-ipc', '--stdio' or '--socket={number}'
    at /opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:3792433
    at t.createConnection (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:3793598)
    at 26997 (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:2:2933803)
    at __webpack_require__ (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:4115664)
    at /opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:4116348
    at Object.<anonymous> (/opt/homebrew/lib/node_modules/intelephense/lib/intelephense.js:7:4116376)
    at Module._compile (node:internal/modules/cjs/loader:1739:14)
    at Object..js (node:internal/modules/cjs/loader:1904:10)
    at Module.load (node:internal/modules/cjs/loader:1473:32)
    at Function._load (node:internal/modules/cjs/loader:1285:12)

Node.js v23.6.0

It appears that the super long message is just the contents of intelephense.js? Any idea what is going on here?

• php
• intelephense

• github/bmewburn/intelephense-docs/blob/master/…, please see the section with Run intelephense {transport} Where {transport} is one of: --node-ipc --stdio --socket={number} --pipe={string} – Full-Stack Developer Commented 2 days ago

1 Answer 1

It appears that the super long message is just the contents of intelephense.js?

No, the output is from node(1) on your computer system, that is the command you have commanded your computer-system to execute.

So what appears to you being the contents of some ECMA Script file (a.k.a. javascript script file) is the output of node(1) executing the script file.

So it is related, but not the same.

Any idea what is going on here?

You are executing a command: intelephense --version

The actual command you execute is named intelephense, what follows after the first field separator are passed as arguments to the command (--version is the single argument that there is).

In the Unix Programming Environment, that is the one on your system that you are making use of, you can identify the pathname of the command with the command special built-in:

$ command -v intelephense
/...

This command invocation is successful if the command name ("intelephense") can be resolved to a pathname. The commands' pathname will be written to the standard output. In your case it must be successful. You can simply try this, command -v is safe to use, it does not execute the command for what follows as command-name (without -v it would however).

Now you have identified the pathname of the actual command you are executing.

This allows you to look into that file with standard file utilities. For example file(1) if you have installed it. But you could also just display the first 10 lines of it with the head(1) utility that should normally be always enabled.

You would then eventually gain the information that it is an executable script file and the executable that is used to execute the script file is the node(1) utility.

This is crucial to understand as it is the only way to explain to yourself how what you see is the "contents" of the script file.

Now as written above, its not exactly the contents, but related. So this is worth to check it out.

The actual contents you face is a so called diagnostic message on the diagnostic channel, also known as standard error. If you would have checked the exit status of your node(1) invocation, it would have likely shown you FAILURE (not SUCCESS).

And if you would have redirected the diagnostic channel, you would not have seen what you describe as the assumed contents of script file at all as it is entirely diagnostic and not the scripts standard output.

These are some of the basic pillars of the Unix Programming Environment you are making use of to execute your development commands. Node(1) is just compatible with these so called standard streams and the exit status.

Read your systems development or maintenance manual what these are. Additionally consult a second source (probably via Wikipedia) to better understand how fundamental these corner-stones are as you will face them not only with javascript script files and node(1) but also with php script files and php(1) and countless other scripts.

Additionally, for what you see on the screen: As node(1) is a script interpreter, it provides debugging information on the diagnostic channel. In your concrete case what you see there is called an error trace or stack trace, also known as backtrace.

Most correctly worded for Node(1) it is an error trace IIRC.

You have been shocked by it because it contains so much information (honestly, actually, very little for a trace, but it's OK). That much information even you conflate it with the contents of the script file itself, at least at the point in time trying to find own words to describe what you see. That's also totally OK. And sure you never conflated it, it was just exactly what you mean. I'm just talking about how it was for me for the first time. YMMV.

But more important and in short, it is just an error.

Errors are totally normal, but remain cumbersome if unexpected and then hard to identify.

Let's make it easy by taking this puzzling output of an error trace apart:

1. It's just an error
2. Every error yielded by Node has a message describing it.
3. Node(1) writes the errors' description in an error trace at the very beginning (starts at the first line)
4. After the error message, the trace is shown. Node writes out what was called (all lines after the message line(s))
5. The trace is from the position in the main script as passed on the command line down (first) to the position where the actual error was thrown/came from (last).

Now only an error comes with a description upfront, it must not mean that we can understand it. However, the description requires reading nevertheless.

(Sometimes an error is just described as "Error", helpful, right?)

Hmm.

A message might not yet speak to us. Then we have to re-read it and re-read it over and over again until it does. To do so, the first thing you have to do is to reproduce the error. Are you able to reproduce the error? So before you re-read the message the second time, reproduce it a second time and then re-read the message. Remember it is only an error, and errors are normal, however errors are always caused, and if you can't cause an error again, you will never be able to understand the description in full. However if you can't reproduce it, you already have gathered other great insights (most often, can't promise you a rose garden).

Simple example: You execute a command and it deletes all files on your system it has access to. So it might even delete the script file itself. You won't be able to reproduce the error until you were able to restore your files from backup.

You probably now think: Who executes commands without reading their documentation how the command is to be executed, a.k.a. invocation? Well, answer that yourself, only those who do, know. Commands provide utility, but only we decide if those utilities are useful for us.

Computers are stupid, humans make errors.

You then reproduce the error over and over again until you understand both the command you execute and the error description you are causing over and over again until you understand how you can cause the error with your command. Theoretically only now, let's read more first:

Now what is the trace then helpful for?

As it shows you all script files that are collaborating to "help" you provoke the error "successfully", you can traverse all scripts and read the source code in there at those locations to understand what the node(1) command that you commanded is doing there. The trace may help you diagnose the error. But there is a caveat: While that will finally result in the situation that you would also understand the description of the error in full, it requires a lot of reading and understanding of the source-code first. This can take endlessly, e.g. the script is under constant change.

But perhaps you were not interesting in debugging the script you are executing? Then this is perhaps not the information you're looking for in the first place but instead you should focus on understanding the command itself you are executing and start with the first script, which is the one on the command line, the first entry in the trace (the entries are sometimes called frames, and the first is the main or entry frame).

Similar to what the documentation of node(1) has about its invocation many scripts designed to run in the Unix Programming Environment, a.k.a. on your command-line, also document their invocation.

Locate the manual/documentation of the script and learn about its invocation if you are not interested in debugging/developing/maintaining the script file itself in the first place.

History has shown, that humans benefit from reading about a command first, before executing it, despite we have to play with each command anyway.

Otherwise, if you are interested in exactly that development work of the command, read the whole documentation of the script file first, then the developer documentation and then read all the source-code.

Perhaps the error handling of that scripts' contents can be easily improved for command-line use if the diagnostic messaging would have been more user-friendly? Perhaps this was caused by a bug? If you can fix it, you have probably finally understood it. Between now and then, there can be quite some journey. Benefit from the documentation that exists, benefit from the code that exists and you'll learn more than you have asked for.

But first read about how to invoke the command in the first place.