counter_isomorphic compile error: hydrate and ssr enabled as features

[agilarity]

Run cargo make test -p counter_isomorphic from leptos/examples to reproduce.

[gbj]

I'm not sure what you're trying to achieve with this (there are no tests for that example). If you use cargo make check, it will avoid the mutually exclusive features that are defined in Cargo.toml. I'm not sure why cargo make test doesn't do that, but it never has if you run it from any of the sub-directories, as far as I know.

[package.metadata.cargo-all-features]
denylist = ["actix-files", "actix-web", "leptos_actix", "stable"]
skip_feature_sets = [["ssr", "hydrate"]]

You can run tests for the separate features separately (cargo test --features=ssr, cargo test --features=hydrate)

[agilarity]

Thank you for looking into this problem for me.

My apologies for not providing context.

The cargo make test-examples task runs tests for all examples. I expect it to run without error, even when no tests exist in a project. It ran without error before I created #904 but failed after I pulled in the latest changes. I thought the new feature checks that were added since then had uncovered problems in some examples.

I ran into the problem when I ran cargo make test-examples. I used cargo make test -p counter_isomorphic in my report to make it easy to verify a specific example.

I am surprised to learn that cargo test and cargo make test do not produce the same results. It is interesting that cargo test works without specifying any features. I wonder why cargo make test fails. I may look into this later.

Thank you for your analysis and kind feedback.

[agilarity]

I learned that the cargo make test task adds the -all-features flag. Removing it resolves the problem.

I will add a PR to fix this.

[gbj]

Ah okay makes perfect sense! Thanks so much for this quick fix and for your work getting us set up to run tests on the examples. I really appreciate it.

EDIT: Just for posterity, I added the compile error on conflicting features after a particularly painful debugging session with someone, not my first, caused by their accidentally having both csr and ssr enabled, which was causing silent misbehavior in the way <Suspense/>/HTML streaming works. I'm glad you figured out a solution to keep the CI working—in the past it had sort of been "well, you should never have both these features enabled but we can't make it an error because it makes cargo make testing harder" which is a pretty sad trade-off. Now we have the best of both.