Rename the extension from sswg.swift-lang to swiftlang.vscode-swift

[plemarquand]

In preparation for the move in the VS Code marketplace, rename the extension ID and associated references in the documentation.

[0xTim]

Is the name fixed? vscode-swift both seems redundant and would suggest it excludes other IDEs that the extension should work in (e.g. #90 )

FWIW all the other 1st class language extensions just use the language name, like golang.Go and rust-lang.rust

[adam-fowler]

I've seen Microsoft do this eg Microsoft.vscode-python but yeah the vscode- still does seem kind of redundant.

[lokesh-tr]

Not sure what the convention is, but I think it would be nice to spell it out as: swiftlang.extension (can be read as "Swift Language Extension"). It feels natural to me, would like to know what you guys think?

[lokesh-tr]

I don't find swiftlang.swift ("Swift Language Swift") and swiftlang.vscode-swift ("Swift Language VS Code Swift") to read out well and it feels redundant

[lokesh-tr]

Checking with the extension's marketplace page, it describes the extension as "Swift Language Support for Visual Studio Code". So, It feels natural for me to name the extension ID as swiftlang.support or swiftlang.extension.

These will go well with tutorials or environment setup guides:
"Install the swiftlang.support extension in your editor" or
"Install the swiftlang.extension in your editor".

If not for these two, going with swiftlang.swift will be better than going with swiftlang.vscode-swift. :)

[plemarquand]

@0xTim I like your point about not being specifically for VS Code; compatible forks are gaining popularity (VS Codium, Cursor). It may be worth doing a pass on the language in the documentation in a follow on PR to refine the language so it's more generic.

[timsneath]

@0xTim, totally get your point about other forks that support VSCode extensions. If there were a consistent generic term that was well understood, that might be an alternative. VSIX is the extension name, but it's a little overloaded with connotations from "full" Visual Studio; there's also VSX (as in, the Open VSX repository).

That said, even in the open repository, they describe it as "extensions for VS Code-compatible editors", which suggests that no other term has yet reached the desired level of general understanding.

The other considerations that went into proposing swiftlang.vscode-swift were:

1. It matches the repository name, so anyone encountering this extension already has an inkling of where to find its home.
2. It is confusion-free both in the Swift context and the Visual Studio context. A user who encounters this on their system will understand what it is and where it comes from.
3. This name is purely used as a unique identifier. We wouldn't / shouldn't use it in user-facing documentation.

@plemarquand Good call on making the language more generic (although we'd need to test the extension in a few other places to really feel comfortable that it doesn't have any hidden dependencies on VSCode: I don't think we test it anywhere else, do we?)

[plemarquand]

@timsneath there aren't any formalized tests with other forks but I've used Cursor casually and the extension has worked great.

VS Codium is basically identical to VS Code but with telemetry disabled so I've got high confidence the extension will work, but I haven't tried loading the .vsix in to it yet. Will make a note that needs to be tested there if we choose to publish to their marketplace.

[adam-fowler]

@plemarquand Good call on making the language more generic (although we'd need to test the extension in a few other places to really feel comfortable that it doesn't have any hidden dependencies on VSCode: I don't think we test it anywhere else, do we?)

I think Apple legal still have to review the terms and conditions to publish on OpenVSX. So we never really treated it as an alternative platform as we weren't publishing to it (although OpenVSX have an unofficial copy up https://open-vsx.org/extension/sswg/swift-lang). Maybe now everything is moving to swiftlang we can organise an OpenVSX version.

[daveyc123]

Yes, once we've wrapped up the work to get the newly identified extension up on the VSCode Marketplace, we'll be working with Apple legal to move forward with the OpenVSX work.

[plemarquand]

The soundness CI failure can be ignored, it is checking for broken links. The updated VS Code marketplace link doesn't exist yet but it will shortly after a new version of the extension is published.