Repository: vscode
Issue: Weird overcaching of code for extension host
Labels: extension-host,under-discussion

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.73.1
- OS Version: Linux x64 4.19.0-22-amd64

I hit a very strange issue with much the same symptoms as #105512. But unlike the reporter of #105512, I wasn't doing any development on extensions.

What I observed was:
 * I upgraded some packages inside the `node_modules/` in my workspace.
 * An extension stopped working. The extension runs ESLint, so its normal operation includes loading modules from the workspace's `node_modules/`.
 * After some debugging, the issue was that when loading (a transitive dependency of) one of those modules, the module loader threw an error inside module "foo" saying "Cannot find module 'bar'"… and indeed there was no file "bar.js", but the actual file "foo.js" on disk doesn't attempt to require any module "bar". The old version of "foo.js", however, did require "bar" (and, in that old version of the package, there was a perfectly good "bar.js".)

<details>
<summary>More-verbose concrete details</summary>

Specifically, in the devtools console, I see:

```
Cannot find module '../internals/define-well-known-symbol'
Require stack:
- /home/greg/z/mobile/node_modules/core-js-pure/modules/es.symbol.async-iterator.js
[…]
```

but the actual file `/home/greg/z/mobile/node_modules/core-js-pure/modules/es.symbol.async-iterator.js` looks like this:
```js
var path = require('../internals/path');
var hasOwn = require('../internals/has-own-property');
var wrappedWellKnownSymbolModule = require('../internals/well-known-symbol-wrapped');
var defineProperty = require('../internals/object-define-property').f;

// … non-`require` code …
```

The old version of that package `core-js-pure` had a file `internals/define-well-known-symbol.js`, which the old version of `modules/es.symbol.async-iterator.js` had a `require` call for. The former file was renamed (to `internals/well-known-symbol-wrapped.js`), and the latter was correctly updated to use the new name. But the module loader is giving us an error that it can't find the old name.

</details>

Starting VS Code with `--no-cached-data` successfully works around the issue, just as in #105512. The issue returns if I later start VS Code again without `--no-cached-data`.

---

Is there any further data I can provide that would help debug why this cached data is being used inappropriately here? The buggy state seems to be stable for me, and `--no-cached-data` lets me smoothly carry on working without disturbing it, so I'm happy to let it remain and to poke at it to answer any questions you have.

Or in the absence of debugging the root cause:  I see that #105512 was closed with https://github.com/microsoft/vscode/commit/8908fba1a0ed2ac8a3ac6de998d0a2abc03290ef . If I'm reading that commit correctly, it disables the code cache when developing extensions. Perhaps the same workaround should be applied for the extension host in general?