Настройка VSCode для разработки в Tauri
Сначала поставим обязательные плагины: Rust-Analyzer (официальная поддержка Rust), Tauri и CodeLLDB (отладчик). Опционально пригодится «Even Better TOML». Для открытых проектов ещё посоветую Codeium — навороченное дополнение с отличным бесплатным тарифом, но шлёт ваш код дяде. Это для всех ОС. В Windows, чтобы работать подобно белому человеку, так же надо установить Windows Terminal и Powershell 7. Установив это всё, закрываем VSCode.
Создаём проект Tauri. Открываем наш проект в корне. Не в папке src-tauri, а в корне! Кстати, если кто ещё не знает: в Windows из проводника можно открыть терминал в текущей папке. Для этого нужно кликнуть по строке адреса и вместо него набрать pwsh. Так или иначе, открываем проект командой code .
Настройка проекта в VSCode производится в основном настройкой файлов в папке .vscode в корне проекта. Официальные инструкции по настройке проекта в Tauri лежат тут. Вот только нифига они не не работают. Если написать, как тут сказано, то сборка и продукт оной конечно будут запускаться, но вот подсветка ошибок и дебаггер будут сбоить. Это всё потому, что предложенный для launch.json блок cargo — это синтаксический сахар, предоставленный расширением CodeLLDB. И он отлично работает для простых проектов Rust, но совершенно не готов к тому, чтобы cargo.toml лежал не в корневой папке проекта.
Вместо этого предлагаю всё настроить по старинке, без этих вот.
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": []
}
]
}
Здесь объявлено 4 задачи.
Project: cargo clippy производит быструю проверку на ошибки.
Project: cargo build devel запускает сборку отладочной версии.
Project: run dev server запускает отладочный сервер.
Project: full release запускает сборку релизной версии.
Блок problemMatcher в задачах объясняет VSCode, что когда Rustc сообщает об ошибке, например, в src/main.rs, то это нужно понимать как /src-tauri/src/main.rs. По сути ради этого блока вся статья и писалась: в lauch.json параметр problemMatcher тоже есть, но не принимает аргументов.
Блок group в задаче cargo clippy вешает её на хоткей Ctrl + Shift +B
Блок runOn: folderOpen автоматически выполняет задачу, когда вы открываете проект. Если ваш проект на одном голом SSR, то отладочный сервер вам не нужен, и можете убрать этот блок.
Теперь файл launch.json. Важно: в нём нужно поменять имя EXE на ваше в двух местах.
{
"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"
},
]
}
Вот теперь можно работать.
Как этим пользоваться
По нажатию Ctrl+Shift+B происходит быстрая проверка кода на ошибки. B здесь в наследство от С++ — там нет clippy и для проверки приходится делать компиляцию. Найденные ошибки будут подсвечены в файлах, а так же перечислены на панели проблем, которая откроется сама. Панель проблем всегда можно открыть и закрыть комбинацией Ctrl+Shift+M (M потому что туда складывается всякая муда). По проблеме можно кликнуть, и перейти сразу на неё.
Отладочная версия проекта Tauri отличается от релизной не только оптимизациями при сборке, но и самой сутью работы. Релизная версия весь JS хранит внутри себя, и является одним файлом. Отладочная же не хранит в себе ничего. Она ожидает, что будет запущен отладочный сервер, и подключится к нему. Это нужно для работы hot reload и других чудес.
В начале каждого сеанса работы с Tauri необходимо запустить отладочный сервер. Если этого не сделать, то, открыв ваше приложение в отладочной сборке, вы вместо интерфейса увидите ошибку 404. Очень забавно. Ничего более страшного не случится. Я автоматизировал запуск отладочного сервера, когда вы открываете проект, но есть одна заковыка: он нагло занимает открытый по умолчанию терминал. Чтобы открыть новый, надо нажать кнопку + в верхнем правом углу панели терминалов.
По нажатию Ctrl+F5 ваша программа скомпилируется и запустится в отладочной сборке. По нажатию просто F5 — то же самое, но с подключённым дебаггером. Надо понимать, что это отладка именно Rust — части программы. Для отладки JS части, в запущенной вашей программе в меню правой кнопки мыши добавлены отладочные опции.
Чтобы собрать релиз, лучше всего набрать npm run tauri build в консоли в корне проекта. Но можно в VSCode перейти в панель дебага (Ctrl+Shift+D) и наверху выбрать Tauri Release, и нажать F5.
Траблошутинг
Самое поганое, с чем можно столкнуться — это когда на Windows отладчик падает через несколько секунд после останова. Проблема известна годами и зависит от версии винды, фазы луны, модели процессора и воли индусов. Решения нет, есть средства избегания:
Напомню, что создание программы из исходных кодов состоит из двух этапов: компиляция и линковка. Rust использует свой компилятор, а вот линковщик берёт сторонний, из MSVC или GCC. Вот тут и проблема.
Чтобы использовать линковщик GCC, его сначала надо установить. Потом набрать в консоли rustup toolchain install stable-x86_64-pc-windows-gnu. И теперь задать проекту target x86_64-pc-windows-gnu Потом удалить все старые следы командой cargo clean.
Для приложений разница должна быть минимальной, а для библиотек перед релизом надо поменять target на windows-msvc. Если найду менее радикальное решение — напишу.
