Setting up VSCode for development in Tauri
First, let's install the required plugins: Rust-Analyzer (official Rust support), Tauri and CodeLLDB (debugger). Optionally, “Even Better TOML” is useful. For open source projects, I would also recommend Codeium – a sophisticated add-on with an excellent free plan, but it sends your code to your uncle. This is for all OS. On Windows, in order to work like a white man, you also need to install Windows Terminal and Powershell 7. Having installed all this, close VSCode.
We are creating the Tauri project. Let's open our project at the root. Not in a folder src-tauribut at the root! By the way, if anyone doesn’t already know: in Windows you can open a terminal in the current folder from Explorer. To do this, click on the address bar and type instead pwsh. One way or another, we open the project with the command code .
Setting up a project in VSCode is mainly done by setting up files in the folder .vscode at the root of the project. Official instructions for setting up a project in Tauri are lying here. But they don’t work anyway. If you write it as it is said here, then the assembly and its product will of course run, but the error highlighting and debugger will fail. This is all because proposed for launch.json block cargo – this is syntactic sugar, provided by the extension CodeLLDB. And it works great for simple Rust projects, but is completely unprepared for cargo.toml not being in the root folder of the project.
Instead, I suggest setting everything up the old fashioned way, without these ones.
tasks.json
{
"version": "2.0.0",
"tasks": [
{
"type": "cargo",
"command": "clippy",
"problemMatcher": {
"base": "$rustc",
"fileLocation": [
"relative",
"${workspaceFolder}/src-tauri"
]
},
"label": "Project: cargo clippy",
"group": {
"kind": "build",
"isDefault": true
},
"options": {
"cwd": "${workspaceFolder}/src-tauri"
}
},
{
"type": "cargo",
"command": "build",
"problemMatcher": {
"base": "$rustc",
"fileLocation": [
"relative",
"${workspaceFolder}/src-tauri"
]
},
"label": "Project: cargo build devel",
"group": {
"kind": "build",
"isDefault": false
},
"options": {
"cwd": "${workspaceFolder}/src-tauri"
}
},
{
"label": "Project: run dev server",
"type": "shell",
"isBackground": true,
"command": "npm",
"args": [
"run",
"dev"
],
"problemMatcher": [],
"runOptions": {
"runOn": "folderOpen"
},
"presentation": {
"reveal": "never",
"panel": "new",
"close": true
}
},
{
"label": "Project: full release",
"type": "shell",
"isBackground": true,
"command": "npm",
"args": [
"run",
"tauri",
"build"
],
"problemMatcher": []
}
]
}
There are 4 tasks announced here.
Project: cargo clippy performs a quick error check.
Project: cargo build development starts building the debug version.
Project: run dev server starts the debug server.
Project: full release starts building the release version.
Block problemMatcher in the tasks VSCode explains that when Rustc reports an error in e.g. src/main.rsthen this must be understood as /src-tauri/src/main.rs. In fact, it was for the sake of this block that the entire article was written: in lauch.json parameter problemMatcher also exists, but does not accept arguments.
Block group in the problem cargo clippy hangs it on the hotkey Ctrl + Shift + B
Block runOn: folderOpen automatically performs the task when you open the project. If your project is on one bare SSR, then you do not need a debug server, and you can remove this block.
Now the file launch.json. Important: you need to change the EXE name to yours in two places.
{
"version": "0.2.0",
"configurations": [
{
"type": "lldb",
"name": "Tauri Development",
"request": "launch",
"program": "${workspaceFolder}/src-tauri/target/debug/application.exe",
"preLaunchTask": "Project: cargo build devel",
},
{
"type": "lldb",
"name": "Tauri Release",
"request": "launch",
"program": "${workspaceFolder}/src-tauri/target/release/application.exe",
"preLaunchTask": "Project: full release"
},
]
}
Now you can work.
How to use it
By pressing Ctrl+Shift+B, the code is quickly checked for errors. B is a legacy of C++ – there is no clippy and you have to compile to check. Errors found will be highlighted in the files, and also listed on the problem panel, which will open itself. The problem panel can always be opened and closed with the combination Ctrl+Shift+M (M because all sorts of mud goes there). You can click on an issue and go straight to it.
The debug version of the Tauri project differs from the release version not only in optimizations during assembly, but also in the very essence of the work. The release version stores all the JS inside itself and is one file. The debugging room does not store anything in itself. It waits for the debug server to be running and connects to it. This is necessary for hot reload and other miracles to work.
At the beginning of each session with Tauri, you must start the debug server. If you don’t do this, then when you open your application in the debug build, you will see a 404 error instead of the interface. Very funny. Nothing worse will happen. I automated the launch of the debug server when you open the project, but there is one catch: it blatantly takes over the terminal that is open by default. To open a new one, you need to click the + button in the upper right corner of the terminal panel.
By pressing Ctrl+F5, your program will compile and run in a debug build. Simply press F5 – the same thing, but with a debugger connected. You need to understand that this is debugging specifically Rust – part of the program. To debug the JS part, debugging options have been added to the right-click menu of your running program.
To build the release, it is best to type npm run tauri build in the console at the root of the project. But you can go to the debug panel in VSCode (Ctrl+Shift+D) and select Tauri Release at the top and press F5.
Trouble Shooting
The worst thing you can encounter is when the debugger crashes on Windows a few seconds after stopping. The problem has been known for years and depends on the version of Windows, the phase of the moon, the processor model and the will of the Indians. There is no solution, there are ways to avoid it:
Let me remind you that creating a program from source code consists of two stages: compilation and linking. Rust uses its own compiler, but the linker is taken from a third-party one, from MSVC or GCC. This is where the problem lies.
To use the GCC linker, you must first install it. Then type in the console rustup toolchain install stable-x86_64-pc-windows-gnu. And now give the project a target x86_64-pc-windows-gnu Then delete all old traces with the command cargo clean.
For applications, the difference should be minimal, but for libraries, before release, you need to change the target to windows-msvc. If I find a less radical solution, I will write.
