Handling imports on WebAssembly

[allsey87]

I would like to use Ruff for a new WebAssembly project and was curious as to how imports can be handled. Is there a way to provide custom hooks/callbacks to provide the requested files to Ruff?

For example, it would be nice if I could provide Ruff with the sources for numpy so that my user's code can be checked against it (correct number of arguments, functions exist etc.).

[MichaReiser]

There's no official way to use ruff from wasm today where we give any stability guarantees or is published to e.g. crates.io.
But you can look at the ruff_wasm crate and our playground if you don't mind building ruff from source or having to deal with breaking API changes.

• ruff_wasm
• Playground callsite

[allsey87]

It seems like ruff_python_resolver is the main crate responsible for figuring out where the imports come from, however, it unfortunately uses std:fs::* directly, so I will have to patch it somehow to support some sort of virtual file system... or target wasm32-unknown-emscripten

[MichaReiser]

Yeah, our architecture isn't yet well made for supporting different file backends. This is probably something we need to change once we start working on multifile analysis where we may need to access unsaved buffers from the IDE instead of the content on disk (CC: @snowsignal )

[snowsignal]

Yes, this is definitely an abstraction we'll need for multi-file analysis in addition to WASM.

[allsey87]

Just out of curiosity, what is meant by multi-file analysis in this context? Would it improve accuracy, performance?

[snowsignal]

Good question! Right now, our linting capabilities are limited by the fact that we can't read from other files during the analysis phase. This is why, for example, we have a typing-modules setting - we can't resolve typing imports directly at this time. Multi-file analysis would enable us to do that.