Proper IDE support for Wasp projects

[Martinsos]

State on 5.7.2023.

Wasp already has LSP support (#204) and a VS Code plugin.

A list of IDE support issues:

• Wasp TS SDK (TypeScript-based Wasp AST generation) #551 - Alternative approach to writing Wasp (different compiler frontend), which might solve some of the challenges with IDE support out of the box, but implies radical changes to how Wasp works.
• Implement language server (LSP) for Wasp #204
• Fix redundant file generation in Wasp #594 - Fixes "duplicate code" reports in IDEs
• Implement formatter for .wasp files #587
• Improve Wasp IDE support for PSL #887
• Connect symbols across the project - this solves: easily renaming a query, jumping to Wasp symbol definitions in Wasp files (e.g., Ctrl+click on an entity should take you to its definition), etc
• Detecting missing JS definitions in Wasp files (e.g., an import from a non-existent JS file) ([waspls] diagnostics for external imports and goto definition #1268)
• Jumping to JS definitions from Wasp files (e.g., query implementations) ([waspls] diagnostics for external imports and goto definition #1268)
• Displaying symbol information on hover

Some of these are probably editor-specific but related. If not, we can later break them up into multiple tasks.

A list of relevant RFCs and docs:

• RFC: Wasp IDE Integration #604

Original issue

When developing a Wasp project, we want all the expected IDE functionalities to be there for the developers. We can focus on VSCode first, but would also want to support other popular editors.

Features we want:

• syntax highlithing/coloring
• formatting
• static analysis
• LSP

And we want this for .wasp files, and also for js/ts/html/css/... files. Also, for pieces of Prisma Schema Language that we use in .wasp files.

This is a big undertaking, and biggest part of it is probably developing LSP for Wasp, and figuring out how to integrate existing LSPs for TS/JS/HTML/... with it, especially while taking into account that Wasp is transpiler and generates code.

We currently have Wasp language extension for VSCode, but it is outdated and does only syntax highlighting, very crude.

Two main directions that we have been thinking about are:

1. Developing Wasp LSP that integrates with / supports LSPs of other languages Wasp uses (HTML/CSS/JS/TS for now, also Prisma Schema Language).
2. Switching from Wasp-lang to Wasp in Typescript and that way possibly achieving easier integration with other languages.

[Martinsos]

Feedback from @joanreyero:

I cannot get my VSCode to figure out the prettier. Especially since a package.json is missing at root, it complains most modules are not found. It is also not prettifying my .wasp file. Do you guys have any .eslint or prettier templates?

Can we provide some quick solution via prettier? At least to get the formatting working?

[Martinsos]

Discussion about an idea on how to get IDE to nicely treat special @wasp imports that we use in files in ext/:

@Martinsos :

Another thought: what if Wasp generated npm package with its runtime and types same as Prisma does? So then that would be imported in the ext/ files (instead of actually non-existing @wasp imports), possibly making it easier for IDE to properly recognize stuff? Ok this is very out of context so I am not expecting us to figure out of this makes sense, just throwing it out here as a "shower thought" (although I was not under shower but programming smth else but still :D).

@shayneczyzewski:

I think for the second one he just means we would output a local package that would be npm installable like other packages, so in their actual code they would not need the fake "@wasp/" path prefix and the IDE would play nicely.

@sodic:

If that's indeed what he ment, it's a very interesting idea! Would we install it ourselves or would the users have to do something extra? (edited)
One problem that comes to mind is that the development process with Wasp is not strictly linear. In other words, you don't write the queries first, the .wasp file after that, and the components last. We do it all at once and the code is pretty entangled. At which step would we generate this librarypackage?

@Martinsos:

I imagine Wasp re-generating that local npm package on each re-compile, based on the current state of the code (.wasp + ext/), similar to how we now generate the codebase. Maybe it would be used both in codebase and during development by IDE, maybe it would be a separate artefact used just by IDE / dev env -> hard to say, not clear to me. Just an idea to have those imports be meaningful and therefore enable IDE to do its job.

[Martinsos]

Btw here is a bit of experimenting in the direction of Wasp via TS: https://github.com/wasp-lang/ast-wasp .

[Martinsos]

Also, I bet there are some other projects out there with similar challenges like this! We should try searching for such projects and investigating how are they implementing their IDE support.

[Martinsos]

Nice idea by @realamirhe -> add the ability to jump between the Wasp definition of Operation (Query, Action) and JS definition of it.