Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Always use the user's tsconfig.json when processing their code #2247

Open
sodic opened this issue Aug 22, 2024 · 2 comments · May be fixed by #2444
Open

Always use the user's tsconfig.json when processing their code #2247

sodic opened this issue Aug 22, 2024 · 2 comments · May be fixed by #2444
Assignees
@sodic

Comments

@sodic
Copy link
Contributor

sodic commented Aug 22, 2024 •
edited
Loading

Note

This issue is related to #1718 but can be solved independently.

Problem

The user code is currently type-checked and built in four different contexts, each with its own errors and reporting.

See the table or graph below for details.

Context Configured by Where it reports errors When it reports errors
VS Code /tsconfig.json Squiggly lines in the IDE While the user is working on their code
SDK .wasp/out/sdk/wasp/tsconfig.json In the terminal, under [Wasp] While building the SDK during wasp start and wasp build
Server .wasp/out/server/tsconfig.json In the terminal, under [Server] While building the server during wasp build *
Client .wasp/out/web-app/tsconfig.json In the terminal, under [Webapp] While building the client during wasp build

* The server does not do any type-checking during wasp compile. See #2458 for details. The web app does (last updated for version 0.15.2).

Untitled-2023-03-16-1448

Solution

We should explore how to always process the user's code exclusively under the rules specified in their tsconfig.json. This is most likely doable with project references: #1827 (comment).

We must do this for all three of our framework's modules (SDK, client, server), and I believe project references are a solution in all three cases.
This was referenced Aug 22, 2024
Open
Open
Open
Open
Open
Open
@Martinsos
Copy link
Member

This is some nice, easy to understand analysis, love it! What did you use to make the diagrams?

@sodic
Copy link
Contributor Author

sodic commented Sep 30, 2024 •
edited
Loading

Users indirectly requesting this (they're requesting simpler imports or tsconfig aliases, but solving this issue is how we make that happen):

I recall many similar requests, but we didn't record them. Still, I'm certain that the lack of support for import aliases is a common hurdle.

@sodic sodic linked a pull request Jan 10, 2025 that will close this issue
Draft
@sodic sodic mentioned this issue Jan 17, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sodic sodic

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Treat user code as a referenced project wasp-lang/wasp
2 participants
@Martinsos @sodic