This PR overhauls extension registration in order to make it more
modular.
The `extension` crate now contains an `ExtensionHostProxy` that can be
used to register various proxies that the extension host can use to
interact with the rest of the system.
There are now a number of different proxy traits representing the
various pieces of functionality that can be provided by an extension.
The respective crates that provide this functionality can implement
their corresponding proxy trait in order to register a proxy that the
extension host will use to register the bits of functionality provided
by the extension.
Release Notes:
- N/A
This PR updates the extension context server registration to go through
the `Extension` trait for interacting with extensions rather than going
through the `WasmHost` directly.
Release Notes:
- N/A
This PR extracts the `VimModeSetting` out of the `vim` crate and into
its own `vim_mode_setting` crate.
A number of crates were depending on the entirety of the `vim` crate
just to reference `VimModeSetting`, which was not ideal.
Release Notes:
- N/A
This PR removes a dependency on the `extensions_ui` from the `title_bar`
crate.
This dependency only existed to reference the `Extensions` action, which
has now been moved to the `zed_actions` crate.
This allows `title_bar` to move up in the crate dependency graph.
Release Notes:
- N/A
This PR moves the tests for the `ExtensionStore` back into the
`extension_host` crate.
We now have a separate `TestExtensionRegistrationHooks` to use in the
test that implements the minimal required functionality needed for the
tests. This means that we can depend on the `theme` crate only in the
tests.
Release Notes:
- N/A
This optimizes and fixes bugs in our logic for maintaining a set of
running context servers, based on the combination of the user's
`context_servers` settings and their installed extensions.
Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR extracts the `ExtensionIndexedDocsProvider` implementation to
the `indexed_docs` crate.
To achieve this, we introduce a new `Extension` trait that provides an
abstracted interface for calling an extension. This trait resides in the
`extension` crate, which has minimal dependencies and can be depended on
by other crates, like `indexed_docs`.
We're then able to implement the `ExtensionIndexedDocsProvider` without
having any knowledge of the Wasm-specific internals of the extension
system.
Release Notes:
- N/A
This fixes the issue of multiple language servers showing up as `node`
in the language server logs dropdown.
It does this by changing `language_server.name()` to return the
adapter's name, not the binary name, and changing types to make sure
that we always use this.
Release Notes:
- Fixed language server names showing up only as `"node"`
---------
Co-authored-by: Sam Rose <hello@samwho.dev>
Co-authored-by: Bennet <bennet@zed.dev>
This PR adds support for context servers provided by extensions.
To provide a context server from an extension, you need to list the
context servers in your `extension.toml`:
```toml
[context_servers.my-context-server]
```
And then implement the `context_server_command` method to return the
command that will be used to start the context server:
```rs
use zed_extension_api::{self as zed, Command, ContextServerId, Result};
struct ExampleContextServerExtension;
impl zed::Extension for ExampleContextServerExtension {
fn new() -> Self {
ExampleContextServerExtension
}
fn context_server_command(&mut self, _context_server_id: &ContextServerId) -> Result<Command> {
Ok(Command {
command: "node".to_string(),
args: vec!["/path/to/example-context-server/index.js".to_string()],
env: Vec::new(),
})
}
}
zed::register_extension!(ExampleContextServerExtension);
```
Release Notes:
- N/A
This contains the main changes to the extensions crate from #20049. The
primary goal here is removing dependencies that we can't include on the
remote.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
This PR renames the `extension` crate to `extension_host`.
This is to free up the name so that we can create a smaller-scoped
`extension` crate.
Release Notes:
- N/A
This PR extends the extensions page with support for upselling built-in
Zed features when certain keywords are searched for.
This should help inform users about features that Zed has out-of-the-box
when they go looking for them as extensions.
For example, when someone searches "vim":
<img width="1341" alt="Screenshot 2024-07-15 at 4 58 44 PM"
src="https://github.com/user-attachments/assets/b256d07a-559a-43c2-b491-3eca5bff436e">
Here are more examples of what the upsells can look like:
<img width="1341" alt="Screenshot 2024-07-15 at 4 54 39 PM"
src="https://github.com/user-attachments/assets/1f453132-ac14-4884-afc4-7c12db47ad1d">
Release Notes:
- Added banners for built-in Zed features when corresponding keywords
are used in the extension search.
This PR adjusts the extension download counts to be displayed using
thousands separators.
Release Notes:
- Adjusted extension download counts to display with thousands
separators (e.g., `1,000,000`).
This PR restricts usage of v0.0.7 of the `zed_extension_api` to dev
builds, for now.
As we're still making changes to it, we don't want to ship a version of
Zed to Preview/Stable that claims to support a yet-unreleased version of
the extension API.
Release Notes:
- N/A
This PR extracts the `SemanticVersion` out of `util` and into its own
`SemanticVersion` crate.
This allows for making use of `SemanticVersion` without needing to pull
in some of the heavier dependencies included in the `util` crate.
As part of this the public API for `SemanticVersion` has been tidied up
a bit.
Release Notes:
- N/A
* [x] auto update extensions on startup
* [ ] add a manual way of updating all?
* [x] add a way to opt out of auto-updates for a particular extension
We don't believe that there should be any background polling for
extension auto-updates, because it could be disruptive to the user.
Release Notes:
- Added an auto-update system for extensions.
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR adds an `zed: Install Local Extension` action, which lets you
select a path to a folder containing a Zed extension, and install that .
When you select a directory, the extension will be compiled (both the
Tree-sitter grammars and the Rust code for the extension itself) and
installed as a Zed extension, using a symlink.
### Details
A few dependencies are needed to build an extension:
* The Rust `wasm32-wasi` target. This is automatically installed if
needed via `rustup`.
* A wasi-preview1 adapter WASM module, for building WASM components with
Rust. This is automatically downloaded if needed from a `wasmtime`
GitHub release
* For building Tree-sitter parsers, a distribution of `wasi-sdk`. This
is automatically downloaded if needed from a `wasi-sdk` GitHub release.
The downloaded artifacts are cached in a support directory called
`Zed/extensions/build`.
### Tasks
UX
* [x] Show local extensions in the Extensions view
* [x] Provide a button for recompiling a linked extension
* [x] Make this action discoverable by adding a button for it on the
Extensions view
* [ ] Surface errors (don't just write them to the Zed log)
Packaging
* [ ] Create a separate executable that performs the extension
compilation. We'll switch the packaging system in our
[extensions](https://github.com/zed-industries/extensions) repo to use
this binary, so that there is one canonical definition of how to
build/package an extensions.
### Release Notes:
- N/A
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This PR moves the Clippy configuration up to the workspace level.
We're using the [`lints`
table](https://doc.rust-lang.org/cargo/reference/workspaces.html#the-lints-table)
to configure the Clippy ruleset in the workspace's `Cargo.toml`.
Each crate in the workspace now has the following in their own
`Cargo.toml` to inherit the lints from the workspace:
```toml
[lints]
workspace = true
```
This allows for configuring rust-analyzer to show Clippy lints in the
editor by using the following configuration in your Zed `settings.json`:
```json
{
"lsp": {
"rust-analyzer": {
"initialization_options": {
"check": {
"command": "clippy"
}
}
}
}
```
Release Notes:
- N/A
- Moves languages module from `zed` into a separate crate. That way we
have less of a long pole at the end of compilation.
- Removes moot dependencies on editor/picker. This is totally harmless
and might help in the future if we decide to decouple picker from
editor.
Before:
```
Number of crates that depend on 'picker' but not on 'editor': 1
Total number of crates that depend on 'picker': 13
Total number of crates that depend on 'editor': 30
```
After:
```
Number of crates that depend on 'picker' but not on 'editor': 5
Total number of crates that depend on 'picker': 12
Total number of crates that depend on 'editor': 26
```
The more crates depend on just picker but not editor, the better in that
case.
Release Notes:
- N/A
This PR adds a view for installing extensions within Zed.
My subtasks:
- [X] Page Extensions and assign in App Menu
- [X] List extensions
- [X] Button to Install/Uninstall
- [x] Search Input to search in extensions registry API
- [x] Get Extensions from API
- [x] Action install to download extension and copy in /extensions
folder
- [x] Action uninstall to remove from /extensions folder
- [x] Filtering
- [x] Better UI Design
Open to collab!
Release Notes:
- Added an extension installation view. Open it using the `zed:
extensions` action in the command palette
([#7096](https://github.com/zed-industries/zed/issues/7096)).
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Carlos <foxkdev@gmail.com>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Max <max@zed.dev>
