Add VS Code extensions

[booniepepper]

Closes #287

Clashes a little with a different approach at #671 since this will consider the VS Code extension marketplace as the default repository

I think we're aligned on this now

The type vsx refers to "VS code eXtension" and seems to be used in multiple places. Open to alternatives like vscode. As a note, the file extension for these IDE extension packages is .vsix.

After discussion, the PR now proposes the type vscode. The previous suggestion of vsx is ambiguous as it could refer to either VS Code extensions (JS) or to Visual Studio extensions (C#) which are incompatible. (Refer to this comment thread)

Happy to hear & take feedback, thanks!

[booniepepper]

@jkowalleck Any thoughts on this?

[mixmix]

As I raised here : #671 (comment) , I'm really interested in how we keep consumers of PURLs safe from things like typosquat attacks. Some context is I work in security and have had a client ask me to review an extension giving just it's name ... and it was really hard to answer their question because I did not know which code I was meant to be auditing! (because there are two registries and they can have different code).

To that end I'm against vsx because I'm scared of it being a foot-gun. I think vscode would be a lot safer.

I think we should explore the question of how we handle referencing extensions in these two registries before merging these PRs though. Propose we continue discussion in that other PR (it's got a bit of discussion already)

[booniepepper]

I have examples in the PR. I think it's easy to distinguish the source by repository_url and this follows the convention used in many other PURL specs.

P.S. I incorporated your changes and credited you in one of the commits included in this PR

P.P.S. I've also been working on software supply chain security for much of the past 5 years

[mixmix]

Update: after some great input from community, have opted to close #671 in favour of this proposal ❤️

[amvanbaren]

Hi! I don't know why, but I got notified about this issue. Any way I can help?

[booniepepper]

@amvanbaren The PR was waiting on me to update (which I have now) -- I'm not sure either, but the more eyes the merrier

[mixmix]

Once again, really appreciate the depth of everyones attention to detail, listening, and thoughtful dialogue. I think we've come to something which is better than any one of alone would have suggesting 🌈 🚀

[booniepepper]

@pombredanne Looks like we've got all the comments addressed. Are you ready to take a look again?

[mixmix]

The encoding of qualifiers is currently being discussed #644

I'd like to propose we side-step that by changing this example to:

Suggested change

	"pkg:vscode/muhammad-sammy/[email protected]?repository_url=https://open-vsx.org",
	"pkg:vscode/muhammad-sammy/[email protected]?repository_url=open-vsx.org",

I notice in the code I'm writing that I'm likely going to just be checking for open-vsx.org because I don't trust users to consistently encode correctly (regardless of what the "correct" way is 😆)

Either way, I'd love to install an open-vsx repository_url in tests/types/vscode-test.json as a clear signal + proof of functionality.

Thoughts @booniepepper ?

[mixmix]

The resolution of that issue is that slashes in qualifers need percentage encoding

Suggested change

	"pkg:vscode/muhammad-sammy/[email protected]?repository_url=https://open-vsx.org",
	"pkg:vscode/muhammad-sammy/[email protected]?repository_url=https:%2F%2Fopen-vsx.org",

I think in practice in my application I'm going to accept all of the following as valid qualifiers (because I know users will get it wrong):

?repository_url=open-vsx.org
?repository_url=open-vsx.org/
?repository_url=https://open-vsx.org
?repository_url=https://open-vsx.org/
?repository_url=https:%2F%2Fopen-vsx.org << probably the most spec-aligned
?repository_url=https:%2F%2Fopen-vsx.org%2F

[matt-phylum]

Your application should be percent decoding the qualifier value, in which case https:%2F%2Fopen-vsx.org and https://open-vsx.org/ are the same. If for some reason you cannot percent decode, you need to look out for https%3A//open-vsx.org/. Whether : is encoded as %3A in qualifiers used to be unclear and IIRC half of the PURL libraries did and half of the PURL libraries didn't.

(If you are using a PURL library, it will normally take care of the decoding for you when it extracts the qualifier value from the string)

[mixmix]

I have feedback from early internal testing that it's quite annoying that the extension is identified by extensionId which uses a . (<publisher>.<name>) in some places, and using a/ delimited path in others (<publisher>/<name>).

Should we consider an alternative which uses the unique package-name like this:

Suggested change

	"pkg:vscode/ms-python/[email protected]",
	"pkg:vscode/ms-python.[email protected]",

Places I've seen /

• package url e.g. https://open-vsx.org/extension/ms-python/python
• the api e.g. https://open-vsx.org/api/my-python/python/2025.16.0

Places I've seen .

• package filename e.g ms-python.python-2025.16.0.vsix
• the api e.g. https://open-vsx.org/api/-/query?extensionId=my-python.python

[rhalar]

The publisher is defined to be the namespace component, which makes sense to me, which is why it's "extracted" from the "VSCode format" into the PURL one resulting in namespace/name.

Maven has a similar convention where they do GroudID:ArtifactID but that also converts to groupid/artifactID in the PURL, for the same reason.
I kind of get the point but if you are constructing PURLs and following the spec there shouldn't be any problems or inconsistencies.

[mixmix]

I think you're right, openvsx even calls it a namespace : https://github.com/EclipseFdn/open-vsx.org/wiki/Guidelines-on-Namespace-Requests

Will mark this resolved

[mixmix]

✅