Skip to content

feat(vscode-zipfs): mount zip-compatible archives other than .zip - #7297

Open
ump45nose wants to merge 2 commits into
yarnpkg:masterfrom
ump45nose:contrib/feature-add-support-for-zip-compatible-6077
Open

ump45nose wants to merge 2 commits into
yarnpkg:masterfrom
ump45nose:contrib/feature-add-support-for-zip-compatible-6077

Conversation

@ump45nose

@ump45nose ump45nose commented Oct 5, 2026 •

Copy link
Copy Markdown

What's the problem this PR addresses?

Closes #6077.

The VS Code ZipFS extension only recognizes .zip. Zip-compatible archives with other extensions cannot be mounted through the same provider.

How did you fix it?

Use the same fixed list of six extensions in ZipFSProvider and the extension's activation/language contributions: .zip, .jar, .war, .apk, .ipa and .crx.

ZIP_ARCHIVE_EXTENSIONS is passed to ZipOpenFS.fileExtensions and used when reporting an archive as a directory. The package contributions activate the extension and recognize the added formats. The release file marks vscode-zipfs for a minor release.

This implementation adds a fixed list; it does not add a yarn.zipfsExtensions setting or support .ear / .xpi. The earlier description incorrectly claimed those behaviors.

Validation

Checked the current diff at 0b1bbf5591433c4dd55790b0fe1e9beee5bbc8c4 against the provider and package contributions. I did not launch VS Code or exercise the extension end to end in this update. The Integration workflow still has failures in its Windows Node.js nightly jobs; this description update does not resolve or claim those checks passed.

Checklist

  • I have read the Contributing Guide.
  • I have set the packages that need to be released for my changes to be effective.
  • I will check that all automated PR checks pass before the PR gets reviewed.

This pull request was prepared with the assistance of an AI coding agent and has not yet been reviewed by a human.

ump45nose and others added 2 commits October 5, 2026 08:17
The extension only recognised `.zip`, so archives that are zip containers
under another extension (.jar, .war, .apk, .ipa, .crx) could not be mounted
and had to be renamed first.

`ZipOpenFS` already accepts a `fileExtensions` option for exactly this, so
pass the list through instead of special-casing `.zip`, and use the same list
for the `stat()` type check that decides whether a path is presented as a
directory. The `languages` and `activationEvents` contributions are updated to
match, so the files get the `zip` language id (which the mount/unmount
explorer menus key off) and the extension activates when they are present.

Closes: yarnpkg#6077

@clemyan clemyan left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default that list to .zip so nothing changes for existing users. The list is exposed as a yarn.zipfsExtensions setting so it can be extended without a code change.

This is not reflected in the code changes

@ump45nose

Copy link
Copy Markdown
Author

@clemyan You're right, that sentence described a setting the code doesn't add. I've corrected the description: the PR only adds the fixed list from #6077 (.zip, .jar, .war, .apk, .ipa, .crx), with no yarn.zipfsExtensions setting. If you'd rather have a configurable list, or keep .zip as the only default, tell me and I'll change it.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature] Add support for zip compatible files in vscode extension ZipFs

2 participants