wgsl-analyzer brings an LSP to WGSL shaders, with Bevy projects left manual
A language server implementation for WGSL and WESL
At a glance
- What is it?
- wgsl-analyzer is a Rust language server for the WebGPU Shading Language, and it also serves WGSL Extended Shader Language as an experimental feature. It gives editors go-to-definition, type checking and completion for shaders, but it cannot infer Cargo dependencies, so Bevy users still hand-write a wesl.toml.
- Who is it for?
- wgsl-analyzer is the right pick for teams editing WGSL or WESL in VS Code, Vim, Emacs or Zed who want type errors and completion without leaving the editor. Skip it if your project depends on automatic dependency discovery through Cargo, since that support is still missing and the Bevy path requires vendoring and a hand-written wesl.toml.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A language server for WGSL, with WESL support flagged as experimental
wgsl-analyzer is a Language Server Protocol plugin for the WebGPU Shading Language. The people who need it are the graphics programmers writing shader code in a Rust or C++ project that targets WebGPU, and who currently have no editor feedback at all on those files because no mainstream editor understands WGSL.
It can be used with any editor that supports the Language Server Protocol, and the README names VS Code, Vim, Emacs and Zed as examples. That matters more than the list itself: because the plugin speaks a standard protocol, adding support for another editor does not require inventing a new integration.
The feature set currently covers go-to-definition, type checking and code completion, and the README says much more is planned. Diagnostics are integrated through naga. Integrated formatting with wgslfmt is present in the README only as a commented-out line, which tells you formatting is not switched on in the shipped configuration.
Support for WESL, the extended version of the shading language, is described as experimental and in progress. The distinction is not cosmetic. WESL adds package structure and imports, which is exactly the part of the problem that this project cannot yet solve automatically, so treat WESL as a preview rather than a settled target.
The crate layout borrows the rust-analyzer blueprint
Internally, wgsl-analyzer is structured as a set of libraries for analyzing Rust code, and the manual has an architecture section for contributors. The workspace manifest makes that structure concrete. It is a Cargo workspace with `crates/*` and `xtask/` as members, and the workspace package block sets edition 2024 and rust-version 1.99.1.
The dependency list names the layers: `syntax` and `parser` for the front end, `hir`, `hir-def` and `hir-ty` for the semantic model, `ide` for editor-facing behaviour, with `ide-completion`, `ide-diagnostics` and `ide-db` below it, and `base-db`, `project-model`, `toolchain`, `vfs`, `vfs-notify` and `paths` underneath that. Some entries in the list are crates from rust-analyzer that are published separately, which explains why the naming and the layering look familiar to anyone who has read that codebase.
That reuse is the mechanism to understand. This is not a single-binary script that scans a file and prints a warning. It is a database-backed analysis stack, which is why it can hold project state, why it needs a discovery step to find roots, and why the manual documents an architecture rather than a command list.
The toolchain crate and the `edition` crate are worth a second look for shader work. Shader languages have their own edition and version story, and the presence of a dedicated `edition` crate suggests version handling is a first-class concern rather than a string comparison buried in the parser.
Building the server and the extension with cargo xtask install
The README points at an installation guide in the manual for the normal path, and then describes building from source. The single command that builds the language server and the extension together is:
cargo xtask installIf you prefer the manual route, the server is built with `cargo build --release -p wgsl-analyzer`, and the extension side needs node modules installed first with `pnpm --dir editors/code install`. The extension can be packaged either as a platform-independent build, with `pnpm --dir editors/code run package`, or as a platform-specific one that bundles the server binary. For the platform-specific route, the binary has to sit in the extension's server directory:
mkdir editors/code/server
cp target/release/wgsl-analyzer editors/code/server/wgsl-analyzerPackaging then takes the target name as an argument:
pnpm --dir editors/code run package --target <target> -o wgsl-analyzer-<target>.vsixThe README gives `linux-x64` as the worked example and says the result is a file such as `editors/code/wgsl-analyzer-linux-x64.vsix`. You then open that file with VS Code and run `Extensions: Install from VSIX...` from the command palette. On Windows the binary is named `wgsl-analyzer.exe` instead, so the copy step differs by one word.
Bevy users still have to write a wesl.toml by hand
This is the sharpest limitation in the project, and the README states it plainly: wgsl-analyzer does not yet support automatically inferring dependencies from package managers such as Cargo. Two open issues track the work, one for inferring path dependencies from `Cargo.toml` and one for WESL dependencies.
The workaround is to vendor Bevy and describe the dependency set explicitly. That means cloning the `bevyengine/bevy` repository locally and putting a `wesl.toml` next to the `Cargo.toml` in the crate that holds the shaders. The manifest starts like this:
# wesl.toml
edition = "2026_pre"
# if you do not put your shaders in the default `./shaders` folder, specify the correct value here
# root = "assets/shaders"The dependencies are then listed as explicit paths, one line per crate:
# it does not hurt to have all of these listed even if you do not use them, but you can trim it to your needs
[dependencies]
bevy_anti_alias = { path = "../bevy/crates/bevy_anti_alias" }
bevy_core_pipeline = { path = "../bevy/crates/bevy_core_pipeline" }
bevy_dev_tools = { path = "../bevy/crates/bevy_dev_tools" }
bevy_feathers = { path = "../bevy/crates/bevy_feathers" }
bevy_gizmos_render = { path = "../bevy/crates/bevy_gizmos_render" }
bevy_pbr = { path = "../bevy/crates/bevy_pbr" }
bevy_post_process = { path = "../bevy/crates/bevy_post_process" }
bevy_render = { path = "../bevy/crates/bevy_render" }
bevy_solari = { path = "../bevy/crates/bevy_solari" }
bevy_sprite_render = { path = "../bevy/crates/bevy_sprite_render" }
bevy_ui_render = { path = "../bevy/crates/bevy_ui_render" }
constants = { path = "../bevy/constants" } # temporary bevy hackThe last line carries an inline comment calling itself a temporary hack, which is a good sign of how provisional this bridge is. The cost is real: the path list has to be maintained by hand as the Bevy tree changes, and it is already long enough that the README suggests trimming it to your needs.
naga on its own versus a language server for live feedback
The obvious alternative is to validate shaders with naga alone, without any editor integration. The difference in approach is visible in this project itself: wgsl-analyzer integrates diagnostics with naga rather than reimplementing shader validation. naga supplies the verdict on whether a shader is valid. wgsl-analyzer supplies everything around that verdict, namely project discovery, the semantic model, completion candidates, and the machinery to report a position inside the file.
If your workflow is a build step that compiles shaders and prints errors in a terminal, that setup is enough and lighter. The moment you want to know the type of a binding while typing, or jump to the function a call refers to, terminal validation stops helping, and that is the gap this project fills.
The other comparison is with rust-analyzer itself. wgsl-analyzer reuses crates published separately from rust-analyzer and arranges its own crates in a similar layering, and the README describes the project as a set of libraries for analyzing Rust code. The consequence for a user is practical: the same mental model, the same discovery concept, and the same expectation that the server keeps a project model in memory rather than re-parsing a single file on every keystroke. The consequence for a reviewer is that shader analysis and Rust analysis end up in one process with one workspace, which is convenient until the two want different roots.
Nightly builds, dated releases and the license files at the root
The project ships a nightly build alongside dated releases, with a nightly published on 2026-10-20, a release on 2026-09-30 and one on 2026-04-26. The last push was on 2026-10-20. A nightly channel for a language server is a normal arrangement, since the server has to match the editor and the shader tooling in use, and dated releases give you something pinned when a nightly breaks.
The repository root also carries release notes and policy files: RELEASES.md, SECURITY.md, CODE_OF_CONDUCT.md and CONTRIBUTING.md, plus tooling configuration such as deny.toml for dependency auditing, clippy.toml, rustfmt.toml, biome.jsonc and flake.nix. The presence of a `RELEASES.md` file means the release history is readable in the repository as well as on the releases page.
On licensing, the repository ships three license files, LICENSE-APACHE, LICENSE-MIT and LICENSE.md, and the workspace manifest declares `license = "MIT OR Apache-2.0"` in the workspace package block. GitHub's own classification for the repository is a custom licence that it cannot classify, which is a discrepancy worth resolving by reading LICENSE.md yourself before shipping it in a product. That is a reading task, not legal advice.
Project discovery is a separate step you will have to configure
Even without Cargo dependency inference, the server still needs to find the files to analyse. The README links to a Project Discovery page in the manual, and the `project-model`, `vfs`, `vfs-notify` and `paths` crates in the workspace are where that lives. `vfs-notify` is the file watching layer, so edits on disk are meant to be picked up without restarting the server.
Where discovery lands matters for real projects. A Bevy workspace has the Rust crate at the top and the shaders in an assets folder, and the manifest in the previous section is the mechanism for pointing the analyzer at those shaders. A shader-only project without any Cargo manifest needs a different answer, and the manual page is where that answer lives rather than the README.
The honest summary of the current state is that this is a usable language server with a well-organised codebase and a clearly documented path for its main ecosystem, but with the package manager integration still open. Everything visible today works on files you have already pointed the server at.
Editorial conclusion
wgsl-analyzer is the right pick for teams editing WGSL or WESL in VS Code, Vim, Emacs or Zed who want type errors and completion without leaving the editor. Skip it if your project depends on automatic dependency discovery through Cargo, since that support is still missing and the Bevy path requires vendoring and a hand-written wesl.toml. Before adopting, verify the extension builds with your toolchain, since the workspace pins rust-version 1.99.1 and edition 2024.
Frequently asked questions
What does wgsl-analyzer add to an editor for WGSL?
It provides go-to-definition, type checking and code completion for WGSL, along with integrated diagnostics through naga. It can be used with any editor that supports the Language Server Protocol, such as VS Code, Vim, Emacs or Zed.
Is WESL support in wgsl-analyzer ready to use?
The README describes support for WESL as experimental and in progress. WESL is the extended version of the shading language and adds package structure, which is the part of the problem the project cannot yet resolve automatically.
How do I use wgsl-analyzer with a Bevy project?
Automatic inference of dependencies from Cargo is not supported yet. The documented route is to vendor Bevy locally, clone the bevyengine/bevy repository, and place a wesl.toml next to the Cargo.toml in the crate holding the shaders, listing each dependency as an explicit path.
How is the wgsl-analyzer VS Code extension built from source?
Run cargo xtask install to build and install everything in one command, or build the server with cargo build --release -p wgsl-analyzer and package the extension with pnpm. The platform-specific route copies the wgsl-analyzer binary into editors/code/server before packaging, producing a vsix file you install with Extensions: Install from VSIX...
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/wgsl-analyzer-wgsl-analyzer)Was this useful?