tauri: [feat] Prevent error when distDir doesn't exist
Describe the problem
If you have a build folder that doesn’t exist, you expect this error from your linter as well as when running cargo check in a GitHub action:
The `distDir` configuration is set to `"../build"` but this path doesn't exist
Describe the solution you’d like
If distDir doesn’t exist, treat it like as an empty directory, but only if an environment variable like TAURI_STRICT_PATHS is not true. When tauri build runs, it should enable TAURI_STRICT_PATHS.
The disadvantage is that running cargo build directly will not panic if distDir doesn’t exist.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 17 (12 by maintainers)
Commits related to this issue
- Add `dist/.gitkeep` to prevent build issues Should prevent error described in https://github.com/tauri-apps/tauri/issues/3142 — committed to wasnotrice/crux by wasnotrice a year ago
It’s also weird to run an apparently innocuous command such as
cargo clippyon CI and have it fail because a directory that is not supposed to be checked in to the tree is indeed not checked in. And the available workarounds are not better:dist/.gitkeepto ensure thatdistexists, but then that empty file will be part of the application embedded assets and there’s no way to prevent that.distDirbefore running any Cargo command that may build the application, but that means that someone will have to externally reinvent the wheel of parsing that file.distdirectory, whencargo clippydoesn’t need it at all?mkdir diston a CI workflow beforehand, but then the workflow has to be changed if thedistDirconfiguration value changes, which is inelegant.I’m not familiar enough with the Tauri build lifecycle to know what would be the best course of action here, but I think that the current behavior is far from ideal, because it makes perfectly valid and fine workflows clunkier for no good reason.
Isn’t it possible to delay that existence check until an attempt to actually embed the assets is made? That sounds like a better idea to me, although I don’t know how feasible it is.
I would not call this terribly simplified. It’s pretty much exactly what’s happening. To expand a bit on what’s happening, tauri’s cli will invoke cargo like so:
tauri dev->cargo build --no-default-features(devPath)tauri build->cargo build --features custom-protocol(distDir)intellij, rust-analyzer, cargo check in cli all by default do just
cargo build/checkwithout saying anything about the features. And because before 6074, custom-protocol was a default feature, and therefore always enabled unless explicitly disabled, the IDEs threw errors because they basically did the equivalent oftauri buildwithout building your frontend first (commonly set as beforeBuildCommand in tauri.conf which also only get’s executed by tauri’s cli, not cargo itself)It shouldn’t be as common anymore since we removed the default features from the templates here: https://github.com/tauri-apps/tauri/pull/6074 (not yet released).
Effectively this means that tauri is in dev mode by default, therefore it looks at the devPath instead of distDir.
Yeah pure Rust users (wasm etc) just go with
cargo runinstead oftauri dev.Pretty much every user will run into this error when creating a Tauri project, and when creating an action that runs
cargo check, then they’ll have to figure out why it’s happening and learn the workaround. It’s a confusing/annoying error because your code works perfectly, but you’re still getting a linting/checking error.I’d love to not see the error anymore, and avoid the extra stuff required to deal with it in actions even though it’s not much.