Web-sys, IntelliJ, jump to class

[zeroexcuses]

This is a repost of Web-sys, intelliJ, GotoClass from > 90 days ago.

Does anyone have "GotoClass" (or any time of jumping) working with Rust / web-sys crate ?

The main issue is that web-sys puts everything behind feature flags, i.e. we have something like:

web_sys = { version = "0.3.45", package = "web-sys", features=["console", 'HtmlImageElement']}

This appears to somehow confuse IntelliJ into not recognizing the HtmlImageElement defined in web_sys, this not allowing me to jump to the class.

In particular, if I open up the IntelliJ "go to class" finder, it can autocomplete / find the 'HtmlImageElement' (so it is somehow parsing the file).

On the other hand, if we have a piece of code like:

let canvas: web_sys::HtmlCanvasElement 

if I put the cursor over the 'HtmlCanvasElement' and try to jump, nothing happens.

Does anyone have jump / auto completion working with web_sys classes ?

[OptimisticPeach]

I believe that intellij rust's name resolution doesn't deal all that well with #[cfg(...)] attributes other than target ones.

When using glam, whose Vec3A type has some #[cfg(...)]s attached, intellij isn't able to suggest anything for name completion. I believe those are feature gated but I don't recognize that being valid feature cfg conditions so I am unsure.

[zeroexcuses]

I have become so dependent upon jumping / auto completion that I am seriously considering maintaing a local 'fork' of web_sys where I manually delete all the cfg flags. (So eveything is always available).

Any potentially less drastic ways to get this to work?

[OptimisticPeach]

If I were so annoyed by it, I would probably do the following: I'd keep a local version of the crate and add a new re-export file which exports all the items I need without any kind of feature gating or anything (instead of doing it only locally since usually the gated items which are exported are private). Then, in my project I'd once again have a re-export file, wherein I could have a module for the modified local version and the crates.io version. I'd comment out the pub use local_name_res::* from that module and uncomment pub use cratesio_name_res::* along with the dependencies when compiling or publishing. This might be a bit overkill, and would require you add something in three places to use it, but I'm fine with that personally, and I think it's a pretty robust approach.