Islands not working with workspace about leptos HOT 9 CLOSED

I had this issue in a workspace, too. Greg helped me on Discord and found out that frontend needs to import the app.

This is my diff from the official example: NiklasEi/start-axum-workspace-islands-ssg@main^^^...main (also turns on SSG)

from leptos.

I think this can probably be closed. I had not realized, but the answer is:

• the frontend/lib crate being compiled to WASM needs to have the app crate as a dependency
• apparently it needs to use app;, if you're in a workspace and there's no use of the app crate otherwise. There seems to be some interaction between wasm-bindgen and cargo here — the islands all get added to the JS module generated as public functions, and if the module is a dependency but totally unused, the glue code doesn't get generated there.

from leptos.

I've been having this issue too, but I believe it might be a general issue with leptos and workspaces rather than with this repo specifically - have you considered filing an issue on the leptos-rs/leptos repo instead?

from leptos.

To be honest I'm a bit confused where to report this kind of an issue. Filing it here here was my best guess.

Also thought of putting it on cargo leptos which is the tool that builds and runs the contents of this repository.

I don't think leptos itself can hold the issue here, workspace just enables code spitting for more complex projects and within the crate feature checking is done against 'itself' with

#[cfg(feature = "experimental-islands")]

I'm not aware of any rust feature checking against workspace Cargo.toml. My point being that if leptos works without workspace setup it should work with it as well.

I suspect it's the build tool that's ignoring the "experimental-islands" feature flag for some stage of frontend build.

BTW it's the feature flag on leptos_axum = { version = "0.5", features = ["experimental-islands"]} that produces the JS console error. Remove "experimental-islands" from that dependency and error goes away.
Obviously nothing works but just to demonstrate that leptos itself is working fine, rendering <leptos-island> component, respecting the feature flag option.

from leptos.

Sorry for the delayed response — for some reason (probably because I was not the original creator) I wasn't getting notifications on that repo.

If you could share steps to reproduce I'd be happy to look at this. The only time I've seen a similar error was when someone had the ssr feature enabled for the client.

from leptos.

To be honest I'm a bit confused where to report this kind of an issue. Filing it here here was my best guess.

Also thought of putting it on cargo leptos which is the tool that builds and runs the contents of this repository.

I don't think leptos itself can hold the issue here, workspace just enables code spitting for more complex projects and within the crate feature checking is done against 'itself' with

#[cfg(feature = "experimental-islands")]

I'm not aware of any rust feature checking against workspace Cargo.toml. My point being that if leptos works without workspace setup it should work with it as well.

I suspect it's the build tool that's ignoring the "experimental-islands" feature flag for some stage of frontend build.

BTW it's the feature flag on leptos_axum = { version = "0.5", features = ["experimental-islands"]} that produces the JS console error. Remove "experimental-islands" from that dependency and error goes away. Obviously nothing works but just to demonstrate that leptos itself is working fine, rendering <leptos-island> component, respecting the feature flag option.

I have experimental_islands working in a workspace. Out of curiosity, are you setting resolver = "2" in you workspace Cargo.toml?

from leptos.

I think this can probably be closed. I had not realized, but the answer is:

* the frontend/lib crate being compiled to WASM needs to have the `app` crate as a dependency

* apparently it needs to `use app;`, if you're in a workspace and there's no use of the app crate otherwise. There seems to be some interaction between wasm-bindgen and cargo here — the islands all get added to the JS module generated as public functions, and if the module is a dependency but totally unused, the glue code doesn't get generated there.

It would be really nice if this could be documented somewhere. I ran into this issue as well, and I didn't realize it was because I removed the use app::*; from frontend until I finally found this issue.

I assume that more people will run into this, as rust-analyzer and cargo check both tell you that this use statement is completely unnecessary, and even just applying the automatic fix using cargo check --fix or something similar simply removes that use statement.

The only "fix" I found for this is to put an allow statement over the import like so:

#[allow(unused_imports)]
use app;

I might also try to open a PR for the book myself.

from leptos.

I think this can probably be closed. I had not realized, but the answer is:

* the frontend/lib crate being compiled to WASM needs to have the `app` crate as a dependency

* apparently it needs to `use app;`, if you're in a workspace and there's no use of the app crate otherwise. There seems to be some interaction between wasm-bindgen and cargo here — the islands all get added to the JS module generated as public functions, and if the module is a dependency but totally unused, the glue code doesn't get generated there.

It would be really nice if this could be documented somewhere. I ran into this issue as well, and I didn't realize it was because I removed the use app::*; from frontend until I finally found this issue.

I assume that more people will run into this, as rust-analyzer and cargo check both tell you that this use statement is completely unnecessary, and even just applying the automatic fix using cargo check --fix or something similar simply removes that use statement.

The only "fix" I found for this is to put an allow statement over the import like so:

#[allow(unused_imports)]
use app;

I might also try to open a PR for the book myself.

That sounds like a great idea. Once we decide islands is not experimental(and it basically isn't now) we should make a couple starters as well

from leptos.

I've added a note about this to the Islands section of the book.

from leptos.