Added remote-ssh extension to /extensions

[bjoaquinc]

Description:

Reworked Open Remote-SSH to work for Void by:

• Adding it to the /extensions folder
• Updating it to npm
• Adding the extension to the gulp file for compiling and building extensions
• Changing DEFAULT_DOWNLOAD_URL_TEMPLATE to point at the void-server release
• Changing all references of the system from VSCodium to Void

Issue:

Resolves #209 by adding a functional Remote-SSH extension

Note:

• The DEFAULT_DOWNLOAD_URL_TEMPLATE is dynamic (https://github.com/voideditor/void-updates-server/releases/download/test/void-server-${os}-${arch}.tar.gz) so the release of this should be available for all os and arch types.
• Will also add version (e.g. 1.0.0) to the void-server tarball file name later on

---

Important

Added Remote-SSH extension for Void platform with updated configurations and build scripts.

• Behavior:
  • Added Remote-SSH extension to /extensions for Void platform.
  • Updated DEFAULT_DOWNLOAD_URL_TEMPLATE to point to Void server release.
  • Changed references from VSCodium to Void.
• Build and Configuration:
  • Updated package.json with new dependencies and scripts for building the extension.
  • Added extension-browser.webpack.config.js and extension.webpack.config.js for webpack configuration.
  • Included extension in gulpfile for compiling and building.
• Misc:
  • Added CHANGELOG.md and README.md for the new extension.
  • Resolved issue SSH Integration #209 by adding a functional Remote-SSH extension.

^{This description was created by for 4950de2. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 4950de2 in 2 minutes and 58 seconds

More details

• Looked at 3050 lines of code in 22 files
• Skipped 4 files when reviewing.
• Skipped posting 7 drafted comments based on config settings.

1. extensions/open-remote-ssh/src/common/files.ts:19

• Draft comment:
  This function duplicates existing functionality. Consider using the existing untildify function instead.

• function untildify (labels.ts)

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50%
  While there is similarity between the functions, they're not identical. The existing function requires passing in userHome while this new one is more specialized for the local case. The regex differences are minor but make them not exactly equivalent. This could be a new specialized version intentionally created for this extension's specific needs.
  I might be overthinking the technical differences - maybe reusing the existing function would still be better even if it means passing in homeDir explicitly.
  While reuse could be good, the comment doesn't provide strong evidence that using the existing function would be better here. The specialized version might be intentional for this extension's use case.
  Delete this comment. While there is similar functionality elsewhere, the differences in implementation and usage patterns mean this isn't clearly a problem that needs fixing.

2. extensions/open-remote-ssh/src/common/disposable.ts:7

• Draft comment:
  This is a duplicate utility function. Consider reusing the existing implementation.

• function disposeAll (dispose.ts)

• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
  While code duplication is generally not ideal, these are in different extensions which may need to be independent. The function is small and simple. Sharing code between extensions might add unnecessary coupling. The comment doesn't provide clear guidance on where/how to share this utility.
  The comment identifies a real issue of code duplication. Having shared utilities could reduce maintenance burden.
  However, the duplication may be intentional to keep extensions decoupled, and the function is simple enough that sharing it may not be worth the added complexity.
  The comment should be deleted as it's not clearly actionable and the duplication may be an intentional design choice for extension independence.

3. extensions/open-remote-ssh/src/authResolver.ts:122

• Draft comment:
  Type assertion uses 'SSHDestination' which is not defined; it seems it should be SSHDestination.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

4. extensions/open-remote-ssh/src/authResolver.ts:307

• Draft comment:
  Typo in log message: change 'forwading' to 'forwarding'.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50%
  While this is technically correct - there is a typo - it's in a log message that only developers would see during debugging. Log message typos don't impact functionality. The rules say not to make purely informative comments and to avoid unimportant changes.
  The typo could make the log message slightly confusing to developers debugging SOCKS forwarding issues. Clear log messages are important for debugging.
  While clear logs are good, this typo is minor and the meaning is still clear from context. The benefit of fixing it is very small compared to the overhead of a PR comment.
  This comment should be deleted as it addresses a minor typo in a log message that doesn't impact functionality.

5. extensions/open-remote-ssh/src/ssh/sshDestination.ts:47

• Draft comment:
  Consider logging the error in the catch block of parseEncoded for easier debugging.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

6. extensions/open-remote-ssh/src/serverSetup.ts:197

• Draft comment:
  Consider validating the result of splitting each line in parseServerInstallOutput to handle unexpected formatting.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

7. extensions/open-remote-ssh/src/ssh/sshConfig.ts:79

• Draft comment:
  Ensure that the 'glob' package version supports promises as used with await in parseSSHConfigFromFile.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

Workflow ID: wflow_KKLZGXev4RSkd5XY

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.