* Update VS Code to 1.92.2
* Use server-main.js to load VS Code
It looks like the bootstrap files are now bundled so we can no longer
require them. We could make them included again, but maybe it is better
to go through the main entrypoint anyway because it includes some nls
stuff which is maybe necessary.
This also fixes what looks like a bug where we could create two servers
if two requests came in. I am not sure what the practical consequences
of that would be, but it will no longer do that.
* Drop es2020 patch
Unfortunately, VS Code will not load with this. It seems to be because
`this` is being used in static properties, and it becomes `void 0` for
some reason under the es2020 target. For example:
static PREFIX_BY_CATEGORY = `${this.PREFIX}${this.SCOPE_PREFIX}`;
becomes
AbstractGotoSymbolQuickAccessProvider.PREFIX_BY_CATEGORY = `${(void 0).PREFIX}${(void 0).SCOPE_PREFIX}`;
Which, obviously, will not work.
Older versions of Safari (and maybe other browsers) are likely affected.
* Fix display language
* Update Playwright
I think maybe because of the dropped es2020 patch that Webkit is now
failing because it is too old.
* Do not wait for networkidle in e2e tests
I am not sure what is going on but some tests on Webkit are timing out
and it seems the page is loaded but something is still trying to
download. Not good, but for now try to at least get the tests passing.
- We have a labeling bot that is marking issues as upstream (so far
correctly) now Ranger is closing them right away and it felt too
aggressive to me.
- It keeps posting its comment twice. Not sure how to fix that.
There is a `yarn ci` script which was using audit-ci but this does not
appear to be called anywhere.
The security worflow uses `yarn audit` and `npm audit` which seem fine
enough anyway.
It is not working. I test this manually anyway so for now just remove
the test, but I think maybe we have to watch for code-server to extract
the language files, and then reload the page, or maybe we have to
install the language from the UI.
Ideally we can drop our patch in the future anyway...
The first argument is a file name, not a path. When the log gets
rotated it prepends the date which ends up creating a path in the
current working directory.
Might make sense to cache the rest as well, and evict from the cache
periodically. For now this is enough to fix a hang I often see in our
deployment of Coder. Might only be surfacing now because new telemetry
calls were added to startup.
It seems that * matches a literal * now, so we have to use a regular
expression.
Parentheses around a parameter no longer works (it causes it to match on
the parameter name literally) and I am not sure why we had it anyway as
it had no effect previously.
Matching with a leading / does not appear to work either, but we do not
need the leading / anyway since the proxy logic was changed to use the
whole path. Consequently it will never be / anymore from what I can
tell but I left that check in just in case. I turned it into a named
parameter as well, because that seems better.
- Remove the redundant title prefix.
- Remove outdated assignees.
- Improve reproduction step description (trying to get folks to submit
more specific/detailed reproductions).
- Render logs with shell (not sure if this actually changes anything).
- Use dropdowns for testing in VS Code and Codespaces. I think the
existing checkboxes are still confusing so hopefully this sorts it.
These checkboxes keep getting checked despite the submitter using an
insecure context or not having tested upstream. I think two things are
at play here:
1. Folks might be interpreting "cannot reproduce" as "did not
reproduce" or "did not have time to reproduce".
2. The checkboxes are required to submit the issue so folks might be
marking them just so they can get their issue submitted; maybe they
are not even reading the checkboxes and are just seeing the error
that they need to be marked and blindly marking them because while
in some cases folks will add "I had to check this but it is not
true", usually they say nothing.
In any case, hopefully these changes make the checkboxes more accurate,
and then if they are unchecked we can ask them to go reproduce in VS
Code or use a secure context or whatever the case may be.
This is just a guard in case there are paths where the workspace is
already marked as initialized but the workspace configuration is not and
we end up actually un-initializing it.
And fix the workspace bug. It is caused by an issue with how some
global variables are being used asynchronously and is exacerbated by the
delay reading settings from the remote introduces.
1. The workspace is created and is marked as not initialized.
2. The configuration's change handler is triggered, and now
initialization is complete.
3. The handler tries to set the global workspace variable to initialized
but the workspace has not been set yet so we get an undefined error.
4. The workspace global is now set, but it is set to the old value with
initialized still set to false.
5. Workspace is never marked as initialized until something else
triggers the on change handler again.
Fixes#3061, and closes#6546.
My guess is this logic changed in one of the VS Code updates,
introducing this async bug but never getting caught probably because for
them the settings are always local thus minimal delay.
The main goal of this patch was to make user settings stored on disk
instead of in the browser, but this stopped working some time ago. Not
only that but it is causing a bug where a workspace will not fully open.
A secondary goal was to fix the Vim extension but the extension appears
to work just fine without this change now (both the server and browser
versions).
This patch is not useful anymore anyway because there are remote-level
settings that *do* get stored on disk and can be used instead of
user-level settings when necessary.
Fixes#3061, and possibly #6153.
This should make it much easier to update. Also use 18.15.0
specifically since that is what VS Code ships with.
Additionally, it fixes the post-install script being skipped due to
a Yarn v1 bug that happens when Yarn installs node-gyp, which
it does because 18.18 onward stopped bundling node-gyp.
Also remove github.com from the trusted domains. This causes the
browser to block the popup instead (probably because the space between
interaction and popup is too great), which is difficult to notice in
Chromium. Even in Firefox with the extra bar they add at the top it can
be easy to miss.
* Fix building from source on arm
Not building from source causes argon2 to pull the wrong arch, so we
have to build from source.
But building from source is causing the new Kerberos module to fail on
arm64 and keytar to fail on both.
The latter has been very difficult to debug because the GitHub image
provides a different result to containers based on Ubuntu 20.04.
Because of this, use a container instead.
Use debian:buster as the container because it is easier to set up the
architecture sources (no need to modify the sources) and because it
seems to come with glibc 2.28 rather than 2.31.
Also use the exact version of Node (18.15.0) for reproducibility.
* Set owner and group during tar to zero
Otherwise you get IDs that can cause (benign) errors while extracting,
which might be confusing. At the very least, I did not see these errors
from previous tars (although they seem to use 1001).
There is no guarantee what IDs might exist so 0 seems the most
reasonable.
The comment said the issue with argon2 was related to CentOS 7 but the
cross-compile steps never used CentOS 7 so maybe the real issue is with
the architecture.
* Avoid packaging yarn.lock
Since the shrinkwrap is what we want everything to use.
* Build with npm
It seems we stuck with yarn because npm was giving us errors but I will try
sorting it out now so we can build with npm as originally intended.
* Remove build from source
Not using CentOS 7 anymore so based on the comment we no longer need
this. Keytar seems to install fine now.
* Update missed Node version
These numbers are all over the place.
* npm_config_arch must be lowercase
* Patch out Kerberos
I am not sure exactly how it is used but I think it is not a path code-server
worries about, at least not right now. Just going to patch it out rather than
figure out how to build it on armv7l but we can revisit later.
* Update dependencies and force-update qs
This is mainly an attempt to get rid of as many resolutions as possible
since it seems they are unnecessary except for qs (according to yarn/npm
audit).
For qs use 6.9.7 since Express is using 6.9.6 and that matches the most
closely.
Also add overrides since this is npm's version of yarn's resolutions and
we need it for the shrinkwrap to generate with the right dependencies.
Decided to keep pinning @types/node as well although I am not sure it is
necessary. Express is pulling in v20 types. Since this is
development-only we only need it in resolutions.
* Run formatter
Some rules seem to have changed with the dependency updates.
* Replace deprecated bodyParser.json() usage
* Audit npm shrinkwrap as well
* Skip installing dependencies in audit
It seems the tools only require the lock files.
* Fix tests when using ipv6
* Add missing openssl dependency to flake
At least, for the standalone and for anyone running on default Node 18.
If support for 2.17 is needed then one would need to build Node 18 with 2.17 and then build code-server with that version (specifically, the native npm modules).
* Update VS Code to 1.82.2
* Add new libkrb5 dependency
* Update patches
The only changes were to context except:
- The URL callback provider uses a new _callbackRoute argument and moved
locations.
- The telemetry provider gets passed the request service as the first
argument now.
- CSP hash changed, as usual.
* Update Node to v18
* Revert back to es2020
es2022 is breaking Safari.
The tilde is ambiguous and it can be helpful to know exactly what paths
code-server is trying to use, especially if it is running as a different
user than you expected.
Asher