Compilation fails with [object object] when UNIX domain socket endpoint files are included in the build

[ty-everett]

• Version: 22.9.1
• Electron Version: 11.3
• Electron Type (current, beta, nightly): current
• Target: darwin

This took me a few hours to sort out, so I thought I would post here and see if a better solution can be implemented.

I was messing around with UNIX domain sockets in my app's root directory. I had an open socket from somewhere else, and when I went to compile my code, it failed with an ambiguous error:

 • electron-builder  version=22.9.1 os=20.3.0
  • loaded configuration  file=package.json ("build" field)
  • writing effective config  file=dist/builder-effective-config.yaml
  • rebuilding native dependencies  [email protected], [email protected] platform=darwin arch=x64
  • packaging       platform=darwin arch=x64 electron=11.3.0 appOutDir=dist/mac
  ⨯ [object Object]
npm ERR! code 1
...

There has been a bug somewhere that has been floating around for some time with the way things are being logged. Of course, once the offending UNIX domain sockets were properly removed things started working again. But issues like #4045 and #4402 (along with my own issue here) would have taken less time to debug if the logs were properly printed.

Anyone know of the source of these [object Object] errors? Seems like someone is passing an object somewhere without using JSON.stringify or something? Or it could be a de-serialization issue. I've seen this sort of behavior in JavaScript before, for example in the browser:

alert({foo: 'bar'}) // [object Object]

Being able to see what the object is that is trying to be printed would make it easier to find the root causes for things.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.