Change:
const userScanOptions: ScanOptions = { includeInvalid: true, profileLocation }; let scannedExtensions: IScannedExtension[] = []; if (type === null || type === ExtensionType.System) { <del> scannedExtensions.push(...await this.extensionsScannerService.scanAllExtensions({ includeInvalid: true }, userScanOptions)); </del> <ins> scannedExtensions.push(...await this.extensionsScannerService.scanAllExtensions({ includeInvalid: true }, userScanOptions, false)); </ins> } else if (type === ExtensionType.User) { scannedExtensions.push(...await this.extensionsScannerService.scanUserExtensions(userScanOptions)); }

Discussion:
Our presubmit tests started to fail consistently since our test setup picked up code 1.67.0 yesterday. Our test is basically doing first, run written with from after the extension tests succeed, run a check on the consistency between our file and documentation/settings info. After running the extension tests with 1.67.0, it looks like the second step that involves reading sees a differently formatted Actually, it's not only a differently formatted , but it includes a new property (, , ...) at the end. The test passes if I make the extension tests to use 1.66.2. We can work around by arranging our presubmit test order or rewriting our test logic to handle this. But, we want to understand what is going on behind the scene and why this modification is necessary. Thanks!
this looks suspicious...
This is designed and expected. It is the metadata VS Code stores per extension while installing that can be used later for other features like updating etc., So I would recommend your extension to handle this.
this has started breaking our extension's tests without warning, and moreover, the way it writes to it's modifying the whole file (looks like whitespace changes).
how have you gone about working around this breaking change? I'm trying to get a release out myself and am suddenly blocked
Whelp, something else went on that broke my tests, but definitely noticed this too and will need to be careful about not committing the reformatted .
Sorry about the caused breakage. I am not sure what is your test doing, but I think it's not a good idea to depend on the content of , because VS Code uses it to write metadata about the extension. We do not remove any existing data but add more data.
What's the recommended way of dealing with the property when testing an extension with set to a version-controlled source directory? Should the changes be committed or do extension authors have to take care of reverting it (which probably means parsing and clearing the property).
I'm currently reverting it. Would love to know if we should do otherwise.
Reopening this to investigate if there is something changed on VS Code while running extension tests
I wanted to re-report this issue, because it was previously misunderstood and closed. Of course I won’t now this is open, but I already typed out reproduction steps. Perhaps they help.

Steps to Reproduce: a git repository (this makes the issue more clear) a minimal VSCode extension with a test. The issue becomes more apparent if an existing extension name / publisher is used. .gitignore and commit we actually reproduce the bug. Run the extension tests Note that running tests has modified . Formatting is changed to use tabs, the final newline is stripped, and publisher metadata is to the file.
To verify: Create some hello world extension and open it's and change the and properties to an extension that already exists in Marketplace. Eg:Quit Code Insiders and Start from CLI with following arguments Make sure hello world extension's is not updated with property
This looks related to which didn't have anything to do with testing the extension, but only debugging it, and getting the same metadata written to an "unsuspecting" Will this fix handle this SO situation as well? The problem occurred very rarely so I couldn't give steps to reproduce, but I was only debugging and not running tests on the extension.
Yes
I have learned more about my situation of getting this extra data when debugging an extension. It happens when the extension writes to the . I have a couple of extensions which allow the user to make settings that will be read and converted to commands. I files a separate issue: