You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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 repoThis’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
yarn link
lib/vscode
The text was updated successfully, but these errors were encountered: