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
-[Commits and commit history](#commits-and-commit-history)
8
+
-[Development workflow](#development-workflow)
9
+
-[Updates to VS Code](#updates-to-vs-code)
10
+
-[Build](#build)
11
+
-[Test](#test)
12
+
-[Unit tests](#unit-tests)
13
+
-[Integration tests](#integration-tests)
14
+
-[End-to-end tests](#end-to-end-tests)
16
15
-[Structure](#structure)
17
16
-[Modifications to VS Code](#modifications-to-vs-code)
18
17
-[Currently Known Issues](#currently-known-issues)
@@ -21,41 +20,49 @@
21
20
22
21
-[Detailed CI and build process docs](../ci)
23
22
24
-
## Pull Requests
25
-
26
-
Please create a [GitHub Issue](https://github.com/cdr/code-server/issues) to address any issue. You can skip this if the proposed fix is minor.
27
-
28
-
In your Pull Requests (PR), link to the issue that the PR solves.
29
-
30
-
Please ensure that the base of your PR is the **main** branch.
31
-
32
-
### Commits
33
-
34
-
We prefer a clean commit history. This means you should squash all fixups and fixup-type commits before asking for review (cleanup, squash, force-push). If you need help with this, feel free to leave a comment in your PR and we'll guide you.
35
-
36
23
## Requirements
37
24
38
-
The prerequisites for contributing to code-server are almost the same as those for
or follow [this tutorial](https://joeprevite.com/verify-commits-on-github)
43
+
-`build-essential` (Linux only - used by VS Code)
44
+
- Get this by running `apt-get install -y build-essential`
55
45
-`rsync` and `unzip`
56
-
- used for code-server releases
46
+
- Used for code-server releases
47
+
48
+
## Creating pull requests
57
49
58
-
## Development Workflow
50
+
Please create a [GitHub Issue](https://github.com/cdr/code-server/issues) that
51
+
includes context for issues that you see. You can skip this if the proposed fix
52
+
is minor.
53
+
54
+
In your pull requests (PR), link to the issue that the PR solves.
55
+
56
+
Please ensure that the base of your PR is the **main** branch.
57
+
58
+
### Commits and commit history
59
+
60
+
We prefer a clean commit history. This means you should squash all fixups and
61
+
fixup-type commits before asking for a review (e.g., clean up, squash, then force
62
+
push). If you need help with this, feel free to leave a comment in your PR, and
63
+
we'll guide you.
64
+
65
+
## Development workflow
59
66
60
67
```shell
61
68
yarn
@@ -65,36 +72,38 @@ yarn watch
65
72
66
73
`yarn watch` will live reload changes to the source.
67
74
68
-
### Updating VS Code
75
+
### Updates to VS Code
69
76
70
-
Updating VS Code requires `git subtree`. On some rpm-based Linux distros, `git subtree` is not included by default, and needs to be installed separately.
71
-
To install, run `dnf install git-subtree` or `yum install git-subtree` as necessary.
77
+
Updating VS Code requires `git subtree`. On some RPM-based Linux distros, `git subtree` is not included by default and needs to be installed separately. To
78
+
install, run `dnf install git-subtree` or `yum install git-subtree`.
72
79
73
-
To update VS Code, follow these steps:
80
+
To update VS Code:
74
81
75
82
1. Run `yarn update:vscode`.
76
-
2. Enter a version. Ex. 1.53
77
-
3. This will open a draft PR for you.
78
-
4. There will be merge conflicts. First commit them.
79
-
1. We do this because if we don't, it will be impossible to review your PR.
80
-
5.Once they're all fixed, test code-server locally and make sure it all works.
81
-
6. Check the version of Node.js that the version of Electron shipped with VSCode uses, and update the version of Node.js if necessary.
82
-
83
-
#### Notes about Changes
83
+
2. Enter a version (e.g., `1.53`)
84
+
3. This will open a draft pull request for you.
85
+
4. There will be merge conflicts. Commit them first, since it will be impossible
86
+
for us to review your PR if you don't.
87
+
5.Fix the conflicts. Then, test code-server locally to make sure everything
88
+
works.
89
+
6. Check the Node.js version that's used by Electron (which is shipped with VS
90
+
Code. If necessary, update your version of Node.js to match.
84
91
85
-
- watch out for updates to `lib/vscode/src/vs/code/browser/workbench/workbench.html`. You may need to make changes to `src/browser/pages/vscode.html`
92
+
> Watch for updates to
93
+
> `lib/vscode/src/vs/code/browser/workbench/workbench.html`. You may need to
94
+
> make changes to `src/browser/pages/vscode.html`.
NOTE: On Linux, the currently running distro will become the minimum supported version.
115
-
In our GitHub Actions CI, we use CentOS 7 for maximum compatibility.
116
-
If you need your builds to support older distros, run the build commands
117
-
inside a Docker container with all the build requirements installed.
123
+
>On Linux, the currently running distro will become the minimum supported
124
+
> version. In our GitHub Actions CI, we use CentOS 7 for maximum compatibility.
125
+
> If you need your builds to support older distros, run the build commands
126
+
> inside a Docker container with all the build requirements installed.
118
127
119
-
##Testing
128
+
### Test
120
129
121
130
There are three kinds of tests in code-server:
122
131
123
-
1.unit tests
124
-
2.integration tests
125
-
3.end-to-end tests
132
+
1.Unit tests
133
+
2.Integration tests
134
+
3.End-to-end tests
126
135
127
-
### Unit Tests
136
+
### Unit tests
128
137
129
-
Our unit tests are written in TypeScript and run using [Jest, the testing framework](https://jestjs.io/).
138
+
Our unit tests are written in TypeScript and run using
139
+
[Jest](https://jestjs.io/), the testing framework].
130
140
131
141
These live under [test/unit](../test/unit).
132
142
133
143
We use unit tests for functions and things that can be tested in isolation.
134
144
135
-
### Integration Tests
145
+
### Integration tests
136
146
137
-
These are a work-in-progress. We build code-server and run a script called [test-standalone-release.sh`](../ci/build/test-standalone-release.sh)
138
-
which ensures that code-server's CLI is working.
147
+
These are a work in progress. We build code-server and run a script called
148
+
[test-standalone-release.sh](../ci/build/test-standalone-release.sh), which
149
+
ensures that code-server's CLI is working.
139
150
140
-
Integration for us means testing things that integrate and rely on each other. For instance, testing the CLI which requires that code-server be built and packaged.
151
+
Our integration tests look at components that rely on one another. For example,
152
+
testing the CLI requires us to build and package code-server.
141
153
142
-
### End-to-End Tests
154
+
### End-to-end tests
143
155
144
-
The end-to-end (e2e) are written in TypeScript and run using [Playwright](https://playwright.dev/).
156
+
The end-to-end (e2e) tests are written in TypeScript and run using
157
+
[Playwright](https://playwright.dev/).
145
158
146
159
These live under [test/e2e](../test/e2e).
147
160
148
-
Before the e2e tests run, we have a `globalSetup` that runs which makes it so you don't have to login before each test and can reuse the authentication state.
161
+
Before the e2e tests run, we run `globalSetup`, which eliminates the need to log
162
+
in before each test by preserving the authentication state.
149
163
150
-
Take a look at `codeServer.test.ts` to see how you use it (look at `test.use`).
164
+
Take a look at `codeServer.test.ts` to see how you would use it (see
165
+
`test.use`).
151
166
152
-
We also have a model where you can create helpers to use within tests. Take a look at [models/CodeServer.ts](../test/e2e/models/CodeServer.ts) to see an example.
167
+
We also have a model where you can create helpers to use within tests. See
168
+
[models/CodeServer.ts](../test/e2e/models/CodeServer.ts) for an example.
153
169
154
-
Generally speaking, e2e means testing code-server running in the browser, similar to how a user would interact with it. When running these tests with `yarn test:e2e`, you must have code-server running locally. In CI, this is taken care of for you.
170
+
Generally speaking, e2e means testing code-server while running in the browser
171
+
and interacting with it in a way that's similar to how a user would interact
172
+
with it. When running these tests with `yarn test:e2e`, you must have
173
+
code-server running locally. In CI, this is taken care of for you.
155
174
156
175
## Structure
157
176
158
-
The `code-server` script serves an HTTP API for login and starting a remote VS Code process.
177
+
The `code-server` script serves as an HTTP API for login and starting a remote VS
178
+
Code process.
159
179
160
-
The CLI code is in [src/node](../src/node) and the HTTP routes are implemented in
161
-
[src/node/routes](../src/node/routes).
180
+
The CLI code is in [src/node](../src/node) and the HTTP routes are implemented
181
+
in [src/node/routes](../src/node/routes).
162
182
163
-
Most of the meaty parts are in the VS Code portion of the codebase under [lib/vscode](../lib/vscode), which we described next.
183
+
Most of the meaty parts are in the VS Code portion of the codebase under
184
+
[lib/vscode](../lib/vscode), which we describe next.
164
185
165
186
### Modifications to VS Code
166
187
167
-
In v1 of code-server, we had a patch of VS Code that split the codebase into a front-end
168
-
and a server. The front-end consisted of all UI code, while the server ran the extensions
169
-
and exposed an API to the front-end for file access and all UI needs.
188
+
In v1 of code-server, we had a patch of VS Code that split the codebase into a
189
+
front-end and a server. The front-end consisted of the UI code, while the server
190
+
ran the extensions and exposed an API to the front-end for file access and all
191
+
UI needs.
170
192
171
-
Over time, Microsoft added support to VS Code to run it on the web. They have made
172
-
the front-end open source, but not the server. As such, code-server v2 (and later) uses
173
-
the VS Code front-end and implements the server. We do this by using a git subtree to fork and modify VS Code. This code lives under [lib/vscode](../lib/vscode).
193
+
Over time, Microsoft added support to VS Code to run it on the web. They have
194
+
made the front-end open source, but not the server. As such, code-server v2 (and
195
+
later) uses the VS Code front-end and implements the server. We do this by using
196
+
a Git subtree to fork and modify VS Code. This code lives under
197
+
[lib/vscode](../lib/vscode).
174
198
175
-
Some noteworthy changes in our version of VS Code:
199
+
Some noteworthy changes in our version of VS Code include:
176
200
177
201
- Adding our build file, which includes our code and VS Code's web code
178
202
- Allowing multiple extension directories (both user and built-in)
179
-
- Modifying the loader, websocket, webview, service worker, and asset requests to
180
-
use the URL of the page as a base (and TLS, if necessary for the websocket)
203
+
- Modifying the loader, WebSocket, webview, service worker, and asset requests to
204
+
use the URL of the page as a base (and TLS, if necessary for the WebSocket)
181
205
- Sending client-side telemetry through the server
182
206
- Allowing modification of the display language
183
207
- Making it possible for us to load code on the client
@@ -191,7 +215,7 @@ us to ensure that our changes are still applied and work as intended. In the fut
191
215
we'd like to run VS Code unit tests against our builds to ensure that features
192
216
work as expected.
193
217
194
-
**Note**: We have [extension docs](../ci/README.md) on the CI and build system.
218
+
>We have [extension docs](../ci/README.md) on the CI and build system.
195
219
196
220
If the functionality you're working on does NOT depend on code from VS Code, please
0 commit comments