Managed to work around the build issues with NPM5 and get a copy of this branch running via ./scripts/code.sh. I rebased onto master before building with ./scripts/npm.sh install

The flowtype extension executes without complaint and without needing to launch vscode from inside a terminal whose CWD is the project directory. I manually instrumented the flowtype extension here to log the process.env.PATH and it appears to include everything. 🎉 🎉 🎉 ✨ 🍰

However, this is still an instance of vscode launched from inside a terminal. I wracked my brains trying to figure out how to produce a double-clickable build from the instructions to no avail. gulp vscode-darwin succeeds but the resulting binary at .build/electron/Code - OSS.app opens up a generic electron window like this:

Attempting to drop various promising-looking files on the DnD target didn't yield anything (various files in out, out-build, and out-vscode.)

Any pointers on how to test this effectively?

@idan If you'd like to run this build, just download it.

cc @idan @NinoFloris

Doing a process.env in this build shows me it actually did not run? still just path defaults.

This is also very clear from the fact Ionide complains it cannot find Mono

That is odd @NinoFloris, as Code should be running path_helper as suggested in #21655. So, apparently, that doesn't fix it.

it should as running path_helper from within fish shell returns a lot of info.
Probably something with the build or the call to path_helper going wrong.

I might be thick but how does getDarwinEnvironment actually return an environment from that func?

it should as running path_helper from within fish shell returns a lot of info.

I might be thick but how does getDarwinEnvironment actually return an environment from that func?

It doesn't launch /usr/libexec/path_helper from fish shell, it just spawns it and parses its result. Launching from within fish shell is a chicken-egg problem... if we could do that, the whole thing would be fixed.

OK, so I looked at how atom is handling this, and it looks like it's the same sort of setup.

After some experimentation, it seems that the wiring of stdout is busted. When I try running path_helper like so from inside code's developer console on my machine, I get the correct $PATH:

(() => {
    const cp = require('child_process')
    const buffers = []
    const child = cp.spawn(process.env.SHELL, ['-lc', 'command /usr/libexec/path_helper'], {encoding: 'utf8', detached: true, stdio: 'pipe'})
    child.on('error', (e) => {
        console.error(e)
    })
    child.stdout.on('data', (data) => {
        buffers.push(data)
    })
    child.on('close', (code, signal) => {
        console.log(Buffer.concat(buffers).toString('utf8'))
    })
})();

The above results in output (redacted) like:

PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:~ALLMYOTHERPATHENTRIES~"; export PATH;

I know that originally this used a stdio setup like ['ignore', 'pipe', process.stderr], but this led to stdout being empty.

If invoked with -i, it produces the same output, but prefixed with a block like:

begin;  function __direnv_export_eval --on-event fish_prompt; 	eval (direnv export fish); end  
 ;end <&3 3<&-
PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:~ALLMYOTHERPATHENTRIES~"; export PATH;

Not sure how this affects other shells yet; but at least it's showing the correct value for me, which is progress. Maybe it's a good clue on how to proceed?

The use of command before path_helper is interesting... I wonder what that does?

https://askubuntu.com/questions/512770/what-is-use-of-command-command

If you remove command from that snippet does it still work?

Yes, using pipe makes your setup work, but pretty much everyone else fail. We tried it and ended up reverting it: 44fcdbf

@idan People over at #21655 say this is no longer an issue. How about for you?

Looks good in 1.19! 😍

Awesome sauce.