Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move vendored VScode to separate fork #3835

Closed
4 tasks done
GirlBossRush opened this issue Jul 21, 2021 · 2 comments
Closed
4 tasks done

Move vendored VScode to separate fork #3835

GirlBossRush opened this issue Jul 21, 2021 · 2 comments
Assignees
Labels
feature New user visible feature
Milestone

Comments

@GirlBossRush
Copy link
Contributor

GirlBossRush commented Jul 21, 2021

Edit: If you’ve been linked here from elsewhere, hello!

This issue was written at time when much of our project was under a major refactor. We’ve since migrated a large portion of our code base to a VS Code fork, which I feel better aligns with Microsoft's conventions to code implementation and organization. Ultimately, I believe that every core addition and change to our fork should eventually find its way upstream as a pull request. At the moment, our two-repo system is Ship of Theseus, but they’ll eventually converge.

If the shared understanding of VS Code’s architecture is our wisdom, then a combined effort is our strength. I’m confident this migration will continue to benefit everyone in the open source community.


It’s no secret, keeping in sync with upstream changes from microsoft/vscode is difficult. Our current arrangement leaves contributors in a tough position, not knowing where our patches alter upstream behavior within lib/vscode. Each new release from upstream often leaves us playing catch-up, stitching patches over large portions of code without much help from our version control tools. And worse, users of code-server are left in the unenviable position of debugging two platforms while simultaneously attempting to do their own job.

Goals

Move lib/vscode to its own repo

This’ll help us immensely in moving along with upstream. We’ll be able to identify our changes, and offer PRs back upstream.

Implement VSCode as an express route.

We already do this to some extent. The only difference is that VS Code specific behaviors will be split from the main branch.

But what if I don’t like change?

That’s alright too, these changes should be transparent for users of code-server without any additional configuration steps. VS Code will continue to be the default experience.

What will code-server do besides host VSCode?

Potentially, any web-based editor, such as RStudio and Jupyter, can be made compatible with code-server. There’s a much larger discussion on how this is done, but starting with our current offering is the first step.

Tasks

  • Update fork to include simplified express server for testing route plugin.
  • Migrate existing patches to fork
  • Include fork in code-server via package.json, possibly via yarn link
  • Remove lib/vscode
@GirlBossRush GirlBossRush added feature New user visible feature needs-investigation This issue needs to be further investigated labels Jul 21, 2021
@GirlBossRush GirlBossRush added this to the 3.12.0 milestone Jul 21, 2021
@GirlBossRush GirlBossRush pinned this issue Jul 21, 2021
@GirlBossRush GirlBossRush self-assigned this Jul 21, 2021
@GirlBossRush
Copy link
Contributor Author

Partially tracked in coder/vscode#2

@GirlBossRush
Copy link
Contributor Author

Closed via #4010 🍾

@jsjoeio jsjoeio unpinned this issue Oct 5, 2021
@code-asher code-asher removed the needs-investigation This issue needs to be further investigated label Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New user visible feature
Projects
None yet
Development

No branches or pull requests

3 participants