systemd, like most 'modern' linux components, has a nice dbus API. This uses
that API to register the tunnel as a service of the calling user.
The dbus dependency is temporarily duplicated, until secret-service 3 is
released, where they update to the latest version (should be a week or two).
For https://github.com/microsoft/vscode-cli/issues/367. Next up, macOS,
then it's done :)
* Initial draft.
Not working.
Also not correctly formatted, I'll do that later.
* Various fixes
It works now
* A bit of cleanup
* Move webServer to its own directory
And prepare for getting rid of dynamicImportCompat.js hack
* Remove dynamicImportCompat.js hack
* Revert unrelated change
* Webpac tsserver.web.js with webServer.ts as entrypoint
Instead of using CopyPlugin.
1. Shipping multiple entrypoints in a single file required fixes to
build code.
2. There are a couple of warnings from `require` calls in
tsserverlibrary.js. Those are not relevant since they're in non-web
code, but I haven't figured how to turn them off; they are fully dynamic
so `externals` didn't work.
* Ignore warnings from dynamic import in tsserver
* Add to .vscodeignore files
For npm modules that have bundled `@vscode/l10n`, they can export their strings to a bundle.l10n.json file which will get picked up by this change and included in the overall bundle for the extension.
* Update messages.es.isl
Add a hotkey to allow opening with Code from the context menu also in Spanish
* fix encoding
Co-authored-by: Joao Moreno <joao.moreno@microsoft.com>
* Bumps @vscode/l10n-dev to a version that supports JS files
* Pulls in JS files (and TSX & JSX) in addition to TS to account for scenarios like Emmet which pulls in @vscode/emmet-helper as an npm package
Past behavior caused 404s to be thrown by the unpkg service because core was trying to load:
`${extensionId}` -> `vscode.markdown`
and not what the build creates in the language packs:
`vscode.${extensionFolder}` -> `vscode.markdown-basics`
this aligns build time and runtime.
Put all win and macOS builds on their own machine, since they take a minute.
Build the two GNU ARM builds together on an x64 machine, since they're
faster and can cross-compile in ~5 minutes.
This makes the CompileCLI step take a little less time than the VS Code
"Compile" step.
The standalone CLI should detect and fall back to using and
system-installed VS Code instance, rather than trying to download zips
and manage its own VS Code instances.
There are three approaches used for discovery:
- On Windows, we can easily and quickly read the register to find
installed versions based on their app ID.
- On macOS, we initially look in `/Applications` and fall back to the
slow `system_profiler` command to list app .app's if that fails.
- On Linux, we just look in the PATH. I believe all Linux installers
(snap, dep, rpm) automatically add VS Code to the user's PATH.
Failing this, the user can also manually specify their installation dir,
using the command `code version use stable --install-dir /path/to/vscode`.
Fixes#164159
Matt Bierner
Henning Dieterichs
Connor Peet
Nathan Shively-Sanders
Tyler James Leonhardt
Ramón Corominas
João Moreno
易良
Logan Ramos
Alexandru Dima
Ladislau Szomoru
Johannes Rieken
Robo
Martin Aeschlimann
Sandeep Somavarapu
Abhishek Singh