Why are optional dev dependencies disabled?

language design
1

Setup:

I am working on a project that uses wai-bindgen-wasmer, which has two features: sys and js. My crate also has those two features, so my Cargo.toml looks something like this:

[dependencies]
wai-bindgen-wasmer = { version = "0.4" }

[features]
sys = ["wai-bindgen-wasmer/sys"]
js = ["wai-bindgen-wasmer/js"]

The problem:

This worked well until I needed to add tests. With the js feature, I also need the wasm-bindgen-test crate. So, I added it as an optional dev dependency:

[dependencies]
wai-bindgen-wasmer = { version = "0.4" }

[dev-dependencies]
wasm-bindgen-test = { version = "0.3", optional = true }

[features]
sys = ["wai-bindgen-wasmer/sys"]
js = ["wai-bindgen-wasmer/js", "wasm-bindgen-test"]

But this gives an error saying that optional dev dependencies are not possible. I do not understand why. I need wasm-bindgen-test only for testing, so it's a dev dependency. And I only need it with the js feature, so it's an optional dev dependency.

Workaround:

I tried googling this, and here a comment suggests making it a normal optional dependency instead, so I came up with this:

[dependencies]
wai-bindgen-wasmer = { version = "0.4" }
wasm-bindgen-test = { version = "0.3", optional = true }

[features]
sys = ["wai-bindgen-wasmer/sys"]
js = ["wai-bindgen-wasmer/js"]
js-test = ["js", "wasm-bindgen-test"]

This works, but it's kind of bad for several reasons:

  1. It creates a new undeeded feature "js-test", which is confusing for both developers and users of the library
  2. It lists wasm-bindgen-test in normal dependencies, even though it is a dev dependency, which again is confusing for the users of the library
  3. When testing, you have to remember to use js-test instead of js, which is an extra burder on the developers.

Moving forward

I don't really understand why optional dev dependencies should be disabled on purpose. Is there a good reason?

Alternatively, is there a better solution to this problem? Including wasm-bindgen-test as a mandatory dev dependency happens to work in my case, but it might not work in other cases where it would pull conflicting crates or features for example.

1 Like
2
1 Like
3

Reading from that thread (second comment):

Should Cargo silently ignore all activated dev-dependencies?

Yes. Cargo already silently ignores all dev-dependencies from a create in that case. Ignoring all dev-dependencies is correct behaviour, regardles of wherher they are activated by a feature of not.

Also, some comments mention using 2 crates to separate the dependencies as a solution. I guess that could work, but it's just another bad workaround instead of actually solving the problem.

4

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.