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

Most upvoted comments

I agree with Amr here, the distDir is part of the application so it would be weird to handle things this way.

It’s also weird to run an apparently innocuous command such as cargo clippy on 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:

  • You can check in a placeholder empty file like dist/.gitkeep to ensure that dist exists, but then that empty file will be part of the application embedded assets and there’s no way to prevent that.
  • It’s possible to parse the Tauri configuration file and create distDir before 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.
  • It’s also possible to build the frontend project before running Cargo commands, but it’s really a good idea to do a full build of it to get a dist directory, when cargo clippy doesn’t need it at all?
  • It’s possible to just run a simple mkdir dist on a CI workflow beforehand, but then the workflow has to be changed if the distDir configuration 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/check without 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 of tauri build without 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 run instead of tauri 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.