* feat: move from yarn to npm
* chore: skip yarn.lock files
* fix: playwright download
* chore: fix compile and hygiene
* chore: bump vsce@2.17.0
Refs https://github.com/microsoft/vscode-vsce/commit/8b49e9dfdf909ad3af2b9ec9c825f5b501f6d75e
* test: update results for bat and sh colorizer tests
* fix: add missing lock files for windows
* fix: switch to legacy-peer-deps
* chore: update markdown-it@14.1.0
Refs https://github.com/markdown-it/markdown-it/commit/737c95a12976357df99652e4b51d831cac4a75aa
esbuild step in extensions-ci-pr was previously using markdown-it
from root which had userland punycode and was able to compile successfully.
* ci: increase pr timeout for windows integration tests
* chore: fix product build
* build: ignore extension dev dependency for rcedit
* build: fix working directory inside container
* build: fix dependency generation
* npm: update dependencies
* ci: use global npmrc
* ci: update cache
* ci: setup global npmrc for private npm auth
* build: fix extension bundling
* chore: sync npm dependencies
* ci: debug env variables for container
* ci: fix win32 cli pipeline
* build: fix npmrc config usage for build/ and remote/ dirs
* fix: windows build
* fix: container builds
* fix: markdown-language-features tests and bundling
```
[03:58:22] Error: Command failed: /Users/demohan/.nvm/versions/node/v20.15.1/bin/node /Users/demohan/github/vscode/extensions/markdown-language-features/esbuild-notebook.js --outputRoot /Users/demohan/github/vscode/.build/extensions/markdown-language-features
✘ [ERROR] Could not resolve "punycode"
extensions/markdown-language-features/node_modules/markdown-it/lib/index.js:14:27:
14 │ var punycode = require('punycode');
╵ ~~~~~~~~~~
The package "punycode" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.
```
Adds userland package based on https://github.com/markdown-it/markdown-it/commit/beed9aee2c1b44819afc25d485e86a6c699b6ef0
* fix: container builds for distro
* chore: update yarn occurrences
* fixup! chore: bump vsce@2.17.0
Uses the closest version to `main` branch that does not
include https://github.com/microsoft/vscode-vsce/commit/d3cc84cdec99b8e9f24be63d1a2a54abe908f68b
while still having the fix https://github.com/microsoft/vscode-vsce/commit/8b49e9dfdf909ad3af2b9ec9c825f5b501f6d75e
* chore: sync npm dependencies
* chore: sync npm dependencies
* chore: sync npm dependencies
* chore: throw error when yarn is used for installation
* chore: add review feedback
* chore: switch exec => run where needed
* chore: npm sync dependencies
* fix: markdown-language-features bundling
```
✘ [ERROR] Could not resolve "punycode"
extensions/markdown-language-features/node_modules/markdown-it/lib/index.js:14:27:
14 │ var punycode = require('punycode');
╵ ~~~~~~~~~~
The package "punycode" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "platform: 'node'" to do that, which will remove this error.
```
Adds missing userland package based on markdown-it/markdown-it@beed9ae,
can be removed once we update markdown-it >= 14.1.0
* ci: rename no-yarn-lock-changes.yml
* chore: sync npm dependencies
* ci: restore no-yarn-lock-changes.yml
We can disable it in a separate PR to keep the required
checks happy and also need workflow edit perms.
* chore: sync npm dependencies
* ci: rebuild cache
* ci: fix no-package-lock-changes.yml
* chore: bump distro
* chore: rm yarn.lock files
* chore: rm yarn.lock files without dependencies
* chore: add vscode-selfhost-import-aid to postinstall dirs
* chore: bump distro
* Fix some always true/false errors in codebase
Testing out latest TS nightly that can identify when an expression is always true/false. This caught a few likely coding mistakes in our codebase
Unsure about the intent in some of these cases but I've tried my best to understand them. Pinging relevant code owners for the confusing cases
* Bump TS version
* Fix unreachable in build scripts
* Bump versions
* restore intent
* Revert package.json change
* Fixing a few new layer checker errors
These are global in node now
* Skip lib check in integration project
* One more skiplibcheck
* More skip lib
---------
Co-authored-by: Benjamin Pasero <benjamin.pasero@gmail.com>
* add integration tests for LanguageModelChat#sendRequest
* make sure errors are recreated when making LM requests
* disable test with a note for later
* fix remote integration tests
* Add more logging and perf markers around resolving the connection token and the socket factory
* set `exposeFunction` earlier
* bla windows
* also expose function for unit tests beofre opening
Co-authored-by: Benjamin Pasero <benjamin.pasero@microsoft.com>
* Allow reusing webview origins across reloads
Currently webviews are always loaded into a unique origin. This keeps them isolated but also means that we can't benefit from caching across window reloads
This change adds a new `origin` option that you can pass to webviews which controls the origin they use. If this origin is not provided, we use a random one instead
We then save off this origin for webview panels and restore it on window reloads. Webviews restore a little faster on window reload
* Update webview fallback version
* web - first cut `yarn web` via our server
* properly pipe output
* web - remove traces of web playground
* web - remember last opened workspace for convinience
* use vscode-test-web for server less, clean up web commands
* fix comment
* fix `yarn web`
* rename to code-server
* open system browser
* code-server script: use minimist
* test resolver: use ./scripts/code-server
* integartion tests: fix code-server command name
Co-authored-by: Martin Aeschlimann <martinae@microsoft.com>
* Revert service worker usage of MessageChannel
Reverts 66b6adf035
While I'm not 100% about this, I think 66b6adf035 causes resourses to occasionally not load. I believe this can happen if the service worker is unitilized while the webview remains active. I can't reproduce this myself so it may be related to memory pressure or resource usage, however relying on the service worker not being reinitilized does seem like a potentially bad idea https://stackoverflow.com/questions/34775105/what-causes-the-global-context-of-a-service-worker-to-be-reset
Will investigate if there's another way to achive this since using MessagePort did clean up the code and slightly improve performance
* Bump webview commit versions
* Switch webview service-worker to use message channel
This change hooks the service worker used for loading webview resources directly up to the main VS Code process over a message channel. Previously this communication had to go through an extra hop through the webview
This simplifies the logic somewhat (although this change required adding extra logic to exchange the message port). It also improves performance a little
* Update webview content commit version
Benjamin Pasero
Robo
Matt Bierner
Johannes Rieken
Martin Aeschlimann
João Moreno
Alpha Romer Coma
Alexandru Dima
Ladislau Szomoru
SteVen Batten
Benjamin Pasero