[Feature] Publish vscode-zipfs to the marketplace

[bradleyayers]

• I'd be willing to implement this feature
• This feature can already be implemented through a plugin

Describe the user story

When using TypeScript and VSCode I find it very useful to be able to navigate to the definition of types, which usually ends up in 3rd party package that are installed through Yarn. The only options I have at the moment are to either unplug the package, reload the VSCode window, and then try again, or to find the source of the package (e.g. on Github) and view it there.

I don't mind unplugging a package when I want to modify it to debug an issue, but for just viewing types or an implementation it would be great for that to be more seamless. This was one of the first issues I was concerned about when I heard about PnP's approach of loading from zips, as viewing 3rd party code is part of my daily workflow.

Describe the solution you'd like

Publish the extension to the VSCode marketplace.

[arcanis]

The extension is very experimental in its current state. Some can be fixed, some are harder. The extension isn't my priority at the moment, so any help we get will be extremely valuable:

"Easy" to fix

• I opened Fixes the build for vscode-zipfs #234 to fix the build

• After that we need to make yarn dlx vsce package work when run from packages/vscode-zipfs

• For that we need to fix a bug in PnP to support require('foo//bar') (rather than just foo/bar) - because it seems they have a typo and rely on this behavior 😅

• After that it seems like they invoke npm -v (why? 🤔), which fails to execute for some reason because it doesn't find semver. This seems to be a regression on Node 12 (works on Node 10), probably because the interface of _resolveFilename changed.

• Once the extension has been packaged and loaded as VSIX, the "Mount as Zip" context command doesn't seem to do anything on my machine (OSX) - I remember that obtaining logs from VSCode was a pain so I haven't debugged further, but given that it worked before it's probably a VSCode interface that changed or something like that.

Hard to fix

• VSCode will print the full archive names in the file bar. It makes it pretty hard to read.

• VSCode doesn't support custom editor views, which makes it impossible to just "open a zip" by opening its file - you need to find it in the project tree view, right click on the archive, click "Mount as Zip", and finally select the file you want to access.

There's a bit of work to do to provide a good experience - so far I've been using emacs to edit the zip archives, but I don't lose hope to see VSCode doing just as well later.

[larixer]

@arcanis Speaking of

VSCode will print the full archive names in the file bar. It makes it pretty hard to read.

Why berry uses so long archive names. Is this necessary?

[arcanis]

Initially the archive names were only hashes, and the name/reference component only appeared later for debugging purposes. We could reevaluate that, I'd just like to be sure that it couldn't cause two different cache entries to share the same name 🤔

Funny story, they're already shorter than they could to be due to an eCryptfs oddity 😅:
https://github.com/yarnpkg/berry/blob/master/packages/berry-core/sources/structUtils.ts#L264

[larixer]

Say you will have 100 000 packages in your project. log2(100 000)=17. It means that for the hash size of 34, according to birthday paradox, the probability of collision will be around 0.5, p=2^33/2^34. Say we want probability to be 1 in a 1 000 000 000 instead. log2(1000000000)=30, it means our hash size should be 63 bits for such collision probability, e.g. p=2^33/2^63. I think 64 bits for the hash size should be enough, even if it is just only hash.

Now we have a different situation. We have also name and version in the package name. How many packages can we have in a project with the same name and same version? :)

[arcanis]

Closing, since the extension has been published (it's still manual though).