Load native windows-process-tree via appRoot (Follow-up to #991)

[ZA139]

This is a follow-up to PR #991.

🎯 Summary

Fixes an issue where the @vscode/windows-process-tree native module failed to load in production. This PR leverages vscode.env.appRoot to locate VS Code's built-in module and uses an eval('require') bypass to circumvent Webpack’s dependency interception.

🔍 Why the previous require() approach failed

In published builds, require('@vscode/windows-process-tree') consistently threw MODULE_NOT_FOUND, causing a silent fallback to WMIC. This was caused by two overlapping technical constraints:

1. Module Resolution Boundaries:
   Since the package is marked as an external in Webpack and excluded from the bundle via .vscodeignore, the installed extension directory contains no node_modules/@vscode/windows-process-tree. Node’s standard resolution algorithm does not look inside VS Code’s own resources/app/node_modules for bare specifiers.
2. Webpack Interception:
   Even if an absolute path is computed via appRoot, Webpack rewrites the standard require() call to __webpack_require__. This internal function is unable to resolve arbitrary absolute filesystem paths outside of the Webpack dependency graph.

As a result, the optimized native code path was never actually exercised in production.

💡 New Design

We now load the module using Node’s native loader by bypassing Webpack's static analysis:

const wpcPath = path.join(env.appRoot, 'node_modules', '@vscode', 'windows-process-tree');
const nodeRequire = eval('require') as NodeJS.Require;
const wpc = nodeRequire(wpcPath);

• Path Resolution: Uses env.appRoot to point directly to the VS Code installation root, where a compatible version of @vscode/windows-process-tree is guaranteed to exist.
• Webpack Bypass: Using eval('require') returns the true Node.js require function. Since Webpack does not analyze the contents of eval, it leaves the call untouched, allowing runtime resolution of the absolute path.
• Robustness & Fallbacks:
  • The entire logic is wrapped in a try/catch block. If the requirement fails (due to ABI mismatch, missing binaries, or older VS Code versions), the existing WMIC fallback remains functional.
  • Extracted the logic into _loadWindowsProcessTree() to allow unit tests to stub the loader without needing a real VS Code environment or eval execution.
• Type Safety: import type is retained for compile-time checks. These are erased during compilation and do not generate any runtime import statements.

// This PR description was generated by AI
// No programmers were harmed in the making of this description

[ZA139]

Previously, local testing was not feasible because VS Code had not yet bumped the internal version of @vscode/windows-process-tree.

The logic has now been successfully verified by local vsix build with WMIC and without it after ver.1.118.0.

[rchiodo]

I believe the way this is handled for other stuff is that VS code would intercept the require and return their implementation. Perhaps they don't do that for windows-process-tree though. I recall this happening for things like the 'vscode' package itself.

[ZA139]

I believe the way this is handled for other stuff is that VS code would intercept the require and return their implementation. Perhaps they don't do that for windows-process-tree though. I recall this happening for things like the 'vscode' package itself.

Yep, I found out other modules like @vscode/extension-telemetry, VS Code's loader does exactly that and intercepts the require call.

Maybe, @vscode/windows-process-tree is a bit of a special case because it’s a native addon containing a .node binary? Since it involves loading machine code that is highly sensitive to the specific OS architecture and Node ABI, it doesn't seem to be part of that standard interception layer. Loading it via appRoot ensures we're hitting the actual binary that matches the running VS Code instance.