Now, every JS/TS-related file will get their package.json script
contents added as tasks:
<img width="1020" alt="image"
src="https://github.com/user-attachments/assets/5bf80f80-fd72-4ba8-8ccf-418872895a25"
/>
To achieve that, `fn associated_tasks` from the `ContextProvider` was
made asynchronous and the related code adjusted.
Release Notes:
- Added initial `package.json` scripts task autodetection
---------
Co-authored-by: Piotr Osiewicz <piotr@zed.dev>
Parses project's package.json to better detect Jasmine, Jest, Vitest and
Mocha and `test`, `build` scripts presence.
Also tries to detect `pnpm` and `npx` as test runners, falls back to
`npm`.
https://github.com/user-attachments/assets/112d3d8b-8daa-4ba5-8cb5-2f483036bd98
Release Notes:
- Improved TypeScript task detection
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
- Languages now define their preferred debuggers in `config.toml`.
- `LanguageRegistry` now exposes language config even for languages that
are not yet loaded. This necessitated extension registry changes (we now
deserialize config.toml of all language entries when loading new
extension index), but it should be backwards compatible with the old
format. /cc @maxdeviant
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
This is a follow up to https://github.com/zed-industries/zed/pull/14821,
which escaped `$` but not `^`.
This is fine for `bash`, but causes issues with `zsh`. This change
escapes the `^`. I tested this against `bash`, `zsh` and `fish`
I suspect such escaping would probably need to be done at some
shell-specific layer of the code, but for now it seems like the tasks
provided by the `ContextProvider` are supposed to be shell agnostic.
To reproduce the original issue:
1. Create a Go test file in a module that just contains a single test
`TestABC`.
2. Run `zsh -i -c "go test -run ^TestABC\$"` which is what Zed tries to
run when the task for a specific Go test is executed.
3. An error that there are no tests to run will be produced even though
there is a test.
4. Run `zsh -i -c "go test -run \^TestABC\$"` (note the backslash before
^).
5. The test will run successfully.
Example:
``` go
package bar
import "testing"
func TestABC(t *testing.T) {}
```
Release Notes:
- fix: Escape the ^ in the Go test -run regex to improve shell
compatibility (notably with zsh).
This is the core change:
https://github.com/zed-industries/zed/pull/26758/files#diff-044302c0d57147af17e68a0009fee3e8dcdfb4f32c27a915e70cfa80e987f765R1052
TODO:
- [x] Use AsyncFn instead of Fn() -> Future in GPUI spawn methods
- [x] Implement it in the whole app
- [x] Implement it in the debugger
- [x] Glance at the RPC crate, and see if those box future methods can
be switched over. Answer: It can't directly, as you can't make an
AsyncFn* into a trait object. There's ways around that, but they're all
more complex than just keeping the code as is.
- [ ] Fix platform specific code
Release Notes:
- N/A
Fix a bug where a GPUI macro still used `ModelContext`
Rename `AsyncAppContext` -> `AsyncApp`
Rename update_model, read_model, insert_model, and reserve_model to
update_entity, read_entity, insert_entity, and reserve_entity
Release Notes:
- N/A
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
Part of https://github.com/zed-industries/zed/issues/22606
Before, `tsdk_path` for vtsls and typescript-language-server
unconditionally set a `tsdk`/`tsserver` property for the corresponding
language server, even if there were no such directory at all.
Instead, make the corresponding code to omit such property if it was not
found on the FS.
Release Notes:
- Fixed "The path /.../tsserver.js doesn't point to a valid tsserver
install. Falling back to bundled TypeScript version." pop-up appearing
Based on the python https://github.com/zed-industries/zed/issues/21452
and PR https://github.com/zed-industries/zed/pull/22587
I found the same problem with go on windows.
Describe the bug / provide steps to reproduce it
Language server error: gopls
The system cannot find the file specified. (os error 2)
-- stderr--
[ERROR project::lsp_store] Failed to start language server "gopls": The
system cannot find the file specified. (os error 2)
[ERROR project::lsp_store] server stderr: ""
Environment
Windows 11
Go
Release Notes:
- Windows: Fixed `gopls` path construction on Windows 11.
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Closes#8071
Release Notes:
- Changed the Go integration to check whether an existing `gopls` was compiled for the current `go` version.
Previously we cached gopls (the go language server) as a file called
`gopls_{GOPLS_VERSION}`. The go version that gopls was built with is
crucial, so we need to cache the go version as well.
It's actually super interesting and very clever; gopls uses go to parse
the AST and do all the analyzation etc. Go exposes its internals in its
standard lib (`go/parser`, `go/types`, ...), which gopls uses to analyze
the user code. So if there is a new go release that contains new
syntax/features/etc. (the libraries `go/parser`, `go/types`, ...
change), we can rebuild the same version of `gopls` with the new version
of go (with the updated `go/xxx` libraries) to support the new language
features.
We had some issues around that (e.g., range over integers introduced in
go1.22, or custom iterators in go1.23) where we never updated gopls,
because we were on the latest gopls version, but built with an old go
version.
After this PR gopls will be cached under the name
`gopls_{GOPLS_VERSION}_go_{GO_VERSION}`.
Most users do not see this issue anymore, because after
https://github.com/zed-industries/zed/pull/8188 we first check if we can
find gopls in the PATH before downloading and caching gopls, but the
issue still exists.
After #18447 was merged, I reviewed the PR code as usual. During this
review, I realized that some code was unintentionally removed when I was
resolving merge conflicts in #18447.
Sorry!
Release Notes:
- N/A
This change ensures we always run LSPs with the project environment (in
addition to any overrides they provide). This helps ensure the
environment is
set correctly on remotes where we don't load the login shell environment
and
assign it to the current process.
Also fixed the go language to use the project env to find the go
command.
Release Notes:
- Improved environment variable handling for SSH remotes
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>
In #17108, we updated `go test ./...` to run against the package
directory, to fix cases in which the top-level project is not the go
module root. However, this leads to the confusing behavior of `go test
./...` only running tests in subdirectories of the current package.
Here, we change the behavior to instead walk up the dirtree to find the
closest `go.mod`, and run the `./...` tasks relative to that directory.
This might lead to more predictable behavior for these tasks.
Also see:
https://github.com/zed-industries/zed/pull/19987#issuecomment-2450159099
Release Notes:
- Improved go test and generate `./...` commands to run against the
current go module directory rather than the current package directory
I was missing the `go generate` runnable from other editors so I figured
I'd implement one here! Now, comments of the form `//go:generate` can
prompt for the `go generate <package>` task. Meanwhile, I've also added
a global `go generate ./...` task.
~When making the global task, I noticed that the existing `go test
./...` task runs tests in subdirectories of the CWD of the active
editor, whereas I would really expect it to run all tests across my
project. I have changed to use the latter behavior (run relative to
project root) for both `go generate ./...` and `go test ./...`. Please
let me know if the prior behavior was intended, and I can revert.~
Release Notes:
- Added runnable and tasks for `go generate` commands
Release Notes:
- Fixed overriding the path of a language server binary for all language
servers. `{"lsp":{"<lsp-name>":{"binary":{"path": "_"}}}}` will now work
for all language servers including those defined by extensions.
- (breaking change) To disable finding lsp adapters in your path, you
must now specify
`{"lsp":{"<lsp-name>":{"binary":{"ignore_system_version": true}}}}`.
Previously this was `{"lsp":{"<lsp-name>":{"binary":{"path_lookup":
false}}}}`. Note that this setting still does not apply to extensions.
- Removed automatic reinstallation of language servers. (It mostly
didn't work)
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
This pushes the new LanguageServerName type to more places.
As both languages and language servers were identified by Arc<str>, it
was
sometimes hard to tell which was intended.
Release Notes:
- N/A
Turns out that #17645 reintroduced another regression and didn't catch
all the regressions in #17108.
Releases Notes:
- Fixed Go tasks not working properly when running tests or benchmarks
in subfolders/packages.
Co-authored-by: Piotr <piotr@zed.dev>
Fixes https://github.com/zed-industries/zed/issues/5291
Release Notes:
- Fixed a bug where the 'toggle comments' command didn't use the right
comment syntax in JSX and TSX elements.
---------
Co-authored-by: Conrad <conrad@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Release Notes:
- Changed built-in language support (Rust, Go, C, YAML, ...) to lookup
language-server specific settings locally in project directory first
before falling back to global value.
---------
Co-authored-by: Bennet <bennet@zed.dev>
This fixes a regression that snuck in with #17108.
When running a single test with `go test` the
regex wouldn't be used anymore.
This restores the old behavior.
Release Notes:
- Fixed a regression when running Go tests. A recent change dropped the
regex used to match single test names when using `go test` in tasks to
run tests. That could lead to more or the wrong tests being run. This
restores the old behavior.
I have found an error running tests in Golang projects that use
submodules. This PR fixes the issue by accessing the directory before
running the test.
The `commons` in the image is a git submodule in a subfolder inside a
parent folder where the workspace is set.
Release Notes:
- Fixed Go tests not being able to run in case the package (and the
`go.mod`) was in a nested folder. Pre-defined Go tasks have been changed
to now run in the package's directory. That means `go test ./package
-run MyTest` will run in `./package` and execute `go test -run MyTest`.
Also, `go test ./...` will run in the package directory, not at the root
of the Zed project, which is a small breaking change. In case one wants
to run `go test ./...` from the root, one can spawn a manual task that
does this.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Closes#15860
Since rust std now supports LazyLock replacing lazy_static with it
reduce the external dependency.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This fixes#14818.
The change in #14055 broke the tasks in `zsh` (and I suspect in `bash`,
`sh` too), because what was executed was NOT
$ go test . -run '^TestThis$'
but instead this:
$ go test . -run \'^TestThis$\'
And in `zsh` this means that `'` is part of the argument passed to `go`,
which means the targeting string is wrong.
Since the problem in `fish` doesn't seem to be the `^` but the `$`, we
can only escape that, which makes the escaped string work in `zsh` and
`fish` and `bash` (in which I've tested this change here)
Release Notes:
- go: Fix running single tests by changing the quoted expression in the
`go test` command to work again in `bash`, `zsh`, etc.
([#14818](https://github.com/zed-industries/zed/issues/14818))
This is already done when selecting a subtest; by wrapping the test name
with `^{}$` the runnable will avoid selecting additional tests with the
same prefix.
Without this fix, selecting the runnable for `TestExample` will also run
`TestExample2`.
Release Notes:
- Fixed Golang tasks spawning tests starting with the current function name and not using the exact match.
Context:
@bennetbo spotted a regression in handling of `cargo run` task in zed
repo following a merge of #13658. We've started invoking `cargo run`
from the folder of an active file whereas previously we did it from the
workspace root. We brainstormed few solutions that involved adding a
separate task that gets invoked at a workspace level, but I realized
that a cleaner solution may be to finally add user-configured task
variables. This way, we can choose which crate to run by default at a
workspace level.
This has been originally brought up in the context of javascript tasks
in
https://github.com/zed-industries/zed/pull/12118#issuecomment-2129232114
Note that this is intended for internal use only for the time being.
/cc @RemcoSmitsDev we should be unblocked on having runner-dependant
tasks now.
Release notes:
- N/A
Release Notes:
- Added support for looking up the `rust-analyzer` binary in `$PATH`. This allows using such tools as `asdf` and nix to configure per-folder rust installations. To enable this behavior, use the `path_lookup` key when configuring the `rust-analyzer` `binary`: `{"lsp": {"rust-analyzer": {"binary": {"path_lookup": true }}}}`.
This PR changes the interface of ContextProvider, allowing it to inspect
*all* variables set so far during the process of building
`TaskVariables`. This makes it possible to capture e.g. an identifier in
tree-sitter query, process it and then export it as a task variable.
Notably, the list of variables includes captures prefixed with leading
underscore; they are removed after all calls to `build_context`, but it
makes it possible to capture something and then conditionally preserve
it (and perhaps modify it).
Release Notes:
- N/A
This uses the language server settings added in #9293 to allow users to
specify the binary path and arguments with which to start up `clangd`.
Example user settings for `clangd`:
```json
{
"lsp": {
"clangd": {
"binary": {
"path": "/usr/bin/clangd",
"arguments": ["--log=verbose"]
},
}
}
}
```
Constraints:
* Right now this only allows ABSOLUTE paths.
Release Notes:
- Added ability to specify `clangd` binary `path` (must be absolute) and
`arguments` in user settings. Example: `{"lsp": {"clangd": {"binary":
{"path": "/usr/bin/clangd", "arguments": ["--log=verbose"] }}}}`
This uses the language server settings added in #9293 to allow users to
specify the binary path and arguments with which to start up `gopls`.
Example user settings for `gopls`:
```json
{
"lsp": {
"gopls": {
"binary": {
"path": "/Users/thorstenball/tmp/gopls",
"arguments": ["-debug=0.0.0.0:8080"]
},
}
}
}
```
Constraints:
* Right now this only allows ABSOLUTE paths.
Release Notes:
- Added ability to specify `gopls` binary `path` (must be absolute) and
`arguments` in user settings. Example: `{"lsp": {"gopls": {"binary":
{"path": "/my/abs/path/gopls", "arguments": ["-debug=0.0.0.0:8080"]
}}}}`
We're doing it. Svelte support is moving into an extension. This PR
fixes some issues that came up along the way.
Notes
* extensions need to be able to retrieve the path the `node` binary
installed by Zed
* previously we were silently swallowing any errors that occurred while
loading a grammar
* npm commands ran by extensions weren't run in the right directory
* Tree-sitter's WASM stdlib didn't support a C function (`strncmp`)
needed by the Svelte parser's external scanner
* the way that LSP installation status was reported was unnecessarily
complex
Release Notes:
- Removed built-in support for the Svelte and Gleam languages, because
full support for those languages is now available via extensions. These
extensions will be suggested for download when you open a `.svelte` or
`.gleam` file.
---------
Co-authored-by: Marshall <marshall@zed.dev>
