Configuration Resolver: figure out process.env behaviour

[bpasero]

It looks like #72029 was triggered by using IWindowConfiguration.userEnv instead of process.env which I did accidentally by my refactorings to bring the configuration resolver service into browser namespace.

@jrieken @joaomoreno can you remind me again when to use process.env vs process.lazyEnv? Should process.env never be used?

My theory is that the resolver service was accessing IWindowConfiguration.userEnv early enough before the process environment was fully resolved.

//cc @alexr00

[jrieken]

Yes, always use process.lazyEnv

[jrieken]

For more detail, until process.lazyEnv isn't resolved process.env isn't complete, e.g on mac/linux we are still resolving bashrc and friends

[jrieken]

For reference: https://github.com/Microsoft/vscode/blob/e0b355177614eee34d38e8b30465b4f02fbef34f/src/vs/code/electron-main/app.ts#L235-L248

[bpasero]

It also seems that process.env has more values initially compared to IWindowConfiguration.userEnv, I wonder if process.env always does a roundtrip to the main side to get most up to date values 🤔 ?

[bpasero]

Ok, this is unrelated to process.env vs process.lazyEnv because the code that gets executed is within a constructor and not top level. I now separated src/vs/workbench/services/configurationResolver/electron-browser/configurationResolverService.ts and src/vs/workbench/services/configurationResolver/browser/configurationResolverService.ts where the one is still using process.env and the other is using IWindowConfiguration.userEnv.