In CI, check for TS errors in built server code (of example app) by running `npx tsc` #2672

cprecioso · 2025-04-15T08:57:38Z

Resolves #2384

Now in CI we type-check the built server and client of waspc/examples/todoApp. I had to modify some types to make it all pass.

I also compiled and tested the other waspc/example/* apps and prompted me to fix some more types

Select what type of change this PR introduces:

Just code/docs improvement (no functional change).
Bug fix (non-breaking change which fixes an issue).
New feature (non-breaking change which adds functionality).
Breaking change (fix or feature that would cause existing functionality to not work as expected).

…unning `npx tsc` Fixes #2384

cprecioso · 2025-04-16T09:35:45Z

waspc/data/Generator/templates/sdk/wasp/server/_types/serialization.ts

-type SerializableJSONValue =
-  | Symbol
+export type SerializableJSONValue =
+  | symbol


Just fixing a TS linting warning here, it's because of the same reason why we shouldn't use String instead of string

Yeah, seems right to me...

But I copied this over from superjson (link in the comment above). And they still have Symbol. Can you open an issue there and see whether we're missing something?

Or you'll help them find a bug - win win 😄

Oh, and what threw this error? I'm not getting anything.

I opened a PR, let's see if they have any complaints: flightcontrolhq/superjson#318
The TypeScript Handbook explicitly calls this out so I'm not sure there's a reason for not merging it: https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#number-string-boolean-symbol-and-object

Oh, and what threw this error? I'm not getting anything.

When I wrote this it was because I thought I got the linting warning. Apparently the linter was my own brain 'cause I can't get it again 😂

cprecioso · 2025-04-16T09:36:21Z

waspc/data/Generator/templates/sdk/wasp/server/_types/serialization.ts

+export type SuperJSONValue =
  | JSONValue
  | SerializableJSONValue
  | SuperJSONArray
  | SuperJSONObject

-interface SuperJSONArray extends Array<SuperJSONValue> {}
+export interface SuperJSONArray extends Array<SuperJSONValue> {}

-interface SuperJSONObject {
+export interface SuperJSONObject {


I need to export these types because other types make reference to them.

Hm, which ones?

I can't find any explicit references, so I'm guessing you meant that some types implicitly depend on them when creating declarations (the "type cannot be named without a reference to..." error).

So I've tried removing the exports from SuperJSONArray, SuperJSONValue, and SerializableJsonValue, rebuilding the SDK, and rebuilding the server. Everything seems to work OK.

Not that exporting these types is a problem (perhaps it's a good thing to do even if it doesn't solve anything), but I'd like to understand what's going on.

I can't find any explicit references, so I'm guessing you meant that some types implicitly depend on them when creating declarations (the "type cannot be named without a reference to..." error).

Yep, exactly.

So I've tried removing the exports from SuperJSONArray, SuperJSONValue, and SerializableJsonValue, rebuilding the SDK, and rebuilding the server. Everything seems to work OK.

Yep me too. I probably moved some stuff around and this is no longer relevant. I can undo if you want.

Oops just remembered, it is only visible in crud-testing:

🐝 --- Building SDK... ------------------------------------------------------------ [ Wasp ] client/crud/tasks.ts(58,14): error TS4023: Exported variable 'tasks' has or is using name 'SuperJSONArray' from external module "/Users/carlos/Developer/Wasp/wasp/waspc/examples/crud-testing/.wasp/out/sdk/wasp/server/_types/serialization" but cannot be named. [ Wasp ] client/crud/tasks.ts(58,14): error TS4023: Exported variable 'tasks' has or is using name 'SuperJSONObject' from external module "/Users/carlos/Developer/Wasp/wasp/waspc/examples/crud-testing/.wasp/out/sdk/wasp/server/_types/serialization" but cannot be named. [ Wasp ] client/crud/tasks.ts(58,14): error TS7056: The inferred type of this node exceeds the maximum length the compiler will serialize. An explicit type annotation is needed.

We should really remove the crud-testing app and move the code to todoApp so we don't have to test out with two different apps. We'll do it when we figure out all example apps.

cprecioso · 2025-04-16T09:37:43Z

waspc/data/Generator/templates/sdk/wasp/server/auth/oauth/provider.ts

@@ -1,13 +1,14 @@
 import { OAuth2Provider, OAuth2ProviderWithPKCE } from "arctic";

 export function defineProvider<
-  OAuthClient extends OAuth2Provider | OAuth2ProviderWithPKCE
+  OAuthClient extends OAuth2Provider | OAuth2ProviderWithPKCE,
+  const Id extends string


Adding the const type parameter makes it output a e.g. {id: "discord"} type instead of a {id: string} one. So then it typechecks correctly for the login provider actions.

Nice improvement!

cprecioso · 2025-04-16T09:38:40Z

waspc/data/Generator/templates/sdk/wasp/server/crud/_operationTypes.ts

@@ -37,7 +37,7 @@ type _WaspEntity = {= crud.entityUpper =}
 /**
 * PUBLIC API
 */
-export namespace {= crud.name =} {
+export declare namespace {= crud.name =} {


Fixing a TS lint, namespaces and modules should not be mixed in the runtime time, so we make it only a type thing.

Hm, can't get this error either. What threw it?

Nothing, just the recommendations on TypeScript's handbook. If we just do export declare there's no output, so no interplay between JS modules and namespaces.

cprecioso · 2025-04-16T09:40:19Z

waspc/data/Generator/templates/sdk/wasp/server/crud/_operationTypes.ts

@@ -79,7 +79,7 @@ export type GetAllQueryResolved = typeof _waspGetAllQuery

 {=# crud.operations.Get =}
 {=^ overrides.Get.isDefined =}
-type GetInput = Prisma.{= crud.entityUpper =}WhereUniqueInput
+type GetInput = SuperJSONObject & Prisma.{= crud.entityUpper =}WhereUniqueInput


The Prisma accepts inputs that are not serializable (e.g. functions), so this intersections makes it select only the kinds of inputs that are.
Otherwise it will fail in the following line as Wasp requires only SuperJSON-serializable inputs.

waspc/data/Generator/templates/sdk/wasp/server/utils.ts

cprecioso · 2025-04-16T09:49:37Z

waspc/data/Generator/templates/server/src/middleware/operations.ts

+{=# isAuthEnabled =}
 import { makeAuthUserIfPossible } from 'wasp/auth/user'
+{=/ isAuthEnabled =}


wasp/auth/user doesn't exist if auth is not enabled

cprecioso · 2025-04-16T09:50:43Z

waspc/data/Generator/templates/server/src/webSocket/initialization.ts

@@ -17,7 +16,7 @@ import { makeAuthUserIfPossible } from 'wasp/auth/user'
 export async function init(server: http.Server): Promise<void> {
  // TODO: In the future, we can consider allowing a clustering option.
  // Ref: https://github.com/wasp-lang/wasp/issues/1228
-  const io: ServerType = new Server(server, {
+  const io = new Server(server, {


We we're not using ServerType anywhere (it's not returned from the function or anything), this line and the following lines were failing if it wasn't a socket.io Server, so I just removed the type annotation.

@infomiho Please comment on this one.

I'm guessing we wanted a relationship between SocketIO and what the user's function receives. But something seems to be missing. This type should have been connected to WebSocketDefinition.

The ServerType is defined based on the user defined handler:

import { webSocketFn as webSocketFn_ext } from 'wasp/src/webSocket' // ... export type ServerType = Parameters<WebSocketFn>[0] // ... type WebSocketFn = typeof webSocketFn_ext

where the wasp/src/webSocket exports:

export const webSocketFn: WebSocketDefinition< ClientToServerEvents, ServerToClientEvents, InterServerEvents > = (io, context) => { // ... } interface ServerToClientEvents { chatMessage: (msg: { id: string; username: string; text: string }) => void } interface ClientToServerEvents { chatMessage: (msg: string) => void } interface InterServerEvents {}

It basically takes the io param and gets its type based on the user defined events. Why this causes a type error - I'm not sure. Maybe there is something off with the way we infer the ServerType type.

It would be great if we can figure it out to have some extra type safety e.g. when users will import the io instance in their server code (currently not possible directly, see: #1289). If it's not possible / too much to do now, let's comment on the issue I linked and solve it in the future.

Found the error, engine.io version mismatch in todo-typescript between user code and .wasp/build/server, I'll see how I can fix

Hey @infomiho let's try to sync up on this because I have some questions on how we could solve it

After talking with Miho, I created this issue #2726. While we fix it, we agreed that the best course of action would be to work around it by removing the type annotation.

sodic

Nice work!

This is a very welcome change. It has potential to be much more useful than just running npx tsc in waspc/todoApp.

We can easily extend it to resolve #2458. Seems like all that's left is:

Reactivating typescript compilation in server's package.json
Double-checking CRUD (the only feature not covered by waspc/todoApp).

If we don't do that now and keep TypeScript "off" for the server code, we'll likely introduce new errors.

So... Can we do it? :)

sodic · 2025-04-28T21:15:17Z

waspc/data/Generator/templates/sdk/wasp/server/_types/serialization.ts

-type SerializableJSONValue =
-  | Symbol
+export type SerializableJSONValue =
+  | symbol


Yeah, seems right to me...

But I copied this over from superjson (link in the comment above). And they still have Symbol. Can you open an issue there and see whether we're missing something?

Or you'll help them find a bug - win win 😄

Oh, and what threw this error? I'm not getting anything.

sodic · 2025-04-28T21:23:39Z

waspc/data/Generator/templates/sdk/wasp/server/_types/serialization.ts

+export type SuperJSONValue =
  | JSONValue
  | SerializableJSONValue
  | SuperJSONArray
  | SuperJSONObject

-interface SuperJSONArray extends Array<SuperJSONValue> {}
+export interface SuperJSONArray extends Array<SuperJSONValue> {}

-interface SuperJSONObject {
+export interface SuperJSONObject {


Hm, which ones?

I can't find any explicit references, so I'm guessing you meant that some types implicitly depend on them when creating declarations (the "type cannot be named without a reference to..." error).

So I've tried removing the exports from SuperJSONArray, SuperJSONValue, and SerializableJsonValue, rebuilding the SDK, and rebuilding the server. Everything seems to work OK.

Not that exporting these types is a problem (perhaps it's a good thing to do even if it doesn't solve anything), but I'd like to understand what's going on.

sodic · 2025-04-28T21:25:37Z

waspc/data/Generator/templates/sdk/wasp/server/auth/oauth/provider.ts

@@ -1,13 +1,14 @@
 import { OAuth2Provider, OAuth2ProviderWithPKCE } from "arctic";

 export function defineProvider<
-  OAuthClient extends OAuth2Provider | OAuth2ProviderWithPKCE
+  OAuthClient extends OAuth2Provider | OAuth2ProviderWithPKCE,
+  const Id extends string


Nice improvement!

sodic · 2025-04-28T21:29:51Z

waspc/data/Generator/templates/sdk/wasp/server/crud/_operationTypes.ts

The changes make sense but please test them if you haven't (the waspc/examples/todoApp doesn't have CRUD so it might have slipped through the cracks).

I did test crud-testing, do you think that covered it?

I think so. crud-testing would be a pretty bad name if it didn't :)

But @infomiho can confirm

Yep, crud-testing covers the CRUD feature 👍

waspc/data/Generator/templates/sdk/wasp/server/utils.ts

sodic · 2025-04-28T21:42:45Z

waspc/data/Generator/templates/server/src/webSocket/initialization.ts

@@ -17,7 +16,7 @@ import { makeAuthUserIfPossible } from 'wasp/auth/user'
 export async function init(server: http.Server): Promise<void> {
  // TODO: In the future, we can consider allowing a clustering option.
  // Ref: https://github.com/wasp-lang/wasp/issues/1228
-  const io: ServerType = new Server(server, {
+  const io = new Server(server, {


@infomiho Please comment on this one.

I'm guessing we wanted a relationship between SocketIO and what the user's function receives. But something seems to be missing. This type should have been connected to WebSocketDefinition.

cprecioso · 2025-04-29T11:30:57Z

@sodic

So... Can we do it? :)

I'd rather leave it for another PR since I don't want to add more cognitive load to this one: #2709

infomiho · 2025-04-29T11:41:27Z

I'll take a look at this PR tomorrow 👍

infomiho

Great addition, left a comment related to the io type, let's figure that before merging

sodic

One more thing and I think we're good to go!

waspc/data/Generator/templates/sdk/wasp/server/utils.ts

waspc/data/Generator/templates/server/src/auth/providers/email/login.ts

cprecioso · 2025-05-06T11:04:25Z

@sodic ready

sodic

A few more questions, but I think this is the final iteration :)

waspc/data/Generator/templates/server/src/auth/providers/email/login.ts

waspc/examples/todoApp/ensure_app_compiles_and_builds.sh

waspc/data/Generator/templates/sdk/wasp/server/utils.ts

sodic

Looks good, awesome work!

Glad this is finally working. It was a big personal frustration for me :)

sodic · 2025-05-09T15:10:15Z

waspc/examples/todoApp/src/rpcTests/operations/fixtures.ts

@@ -10,5 +10,6 @@ export const SERIALIZABLE_OBJECTS_FIXTURE = {
  negInf: -Infinity,
  // we ensure that it'd be too big to be represented as a `number`
  decimal: new Prisma.Decimal(Number.MAX_SAFE_INTEGER).mul(2),
+  // @ts-ignore Server has a tsconfig target of es2017, so BigInt isn't available


Can we update the server tsconfig? We can do it in a different PR and remove this comment.

If it turns out to cause problems, we can create an issue and link it here.

cprecioso self-assigned this Apr 15, 2025

cprecioso force-pushed the cprecioso/issue2384 branch 2 times, most recently from e23663d to 488013d Compare April 15, 2025 09:45

cprecioso changed the base branch from main to filip-sdk-tsconfig April 15, 2025 09:45

cprecioso added 2 commits April 15, 2025 12:10

In CI, check for TS errors in built server code (of example app) by r…

962aae0

…unning `npx tsc` Fixes #2384

Fix TypeScript errors

8029635

cprecioso force-pushed the cprecioso/issue2384 branch from 488013d to 8029635 Compare April 15, 2025 10:13

cprecioso changed the base branch from filip-sdk-tsconfig to main April 15, 2025 10:14

cprecioso added 3 commits April 15, 2025 12:50

Update snapshots

5a3fc28

Update CRUD types

3d5e4b9

Update snapshots

6ec83ed

cprecioso requested review from sodic and infomiho and removed request for sodic April 16, 2025 08:44

This comment was marked as outdated.

Sign in to view

Remove extra file

1d6ad57

cprecioso commented Apr 16, 2025

View reviewed changes

cprecioso marked this pull request as ready for review April 16, 2025 09:41

cprecioso added 3 commits April 16, 2025 11:47

Update package-lock

1ed82db

Update templates

d98a81e

Update snapshots

7691171

cprecioso commented Apr 16, 2025

View reviewed changes

sodic reviewed Apr 28, 2025

View reviewed changes

This was referenced Apr 29, 2025

Use symbol instead of Symbol flightcontrolhq/superjson#318

Open

Typecheck server code in build and CI #2709

Closed

infomiho reviewed Apr 30, 2025

View reviewed changes

Undo type change

c5ef5fb

sodic reviewed May 5, 2025

View reviewed changes

waspc/data/Generator/templates/sdk/wasp/server/utils.ts Outdated Show resolved Hide resolved

sodic reviewed May 5, 2025

View reviewed changes

waspc/data/Generator/templates/sdk/wasp/server/utils.ts Outdated Show resolved Hide resolved

cprecioso mentioned this pull request May 6, 2025

Ensure the different generated packages are using the same transitive dependencies #2726

Open

cprecioso added 4 commits May 6, 2025 12:09

Add a todo

4e484ce

Merge remote-tracking branch 'origin/main' into cprecioso/issue2384

7098670

Fix errors

c7fb8b8

Snapshots

5d40891

cprecioso commented May 6, 2025

View reviewed changes

waspc/data/Generator/templates/server/src/auth/providers/email/login.ts Show resolved Hide resolved

sodic reviewed May 7, 2025

View reviewed changes

waspc/data/Generator/templates/server/src/auth/providers/email/login.ts Show resolved Hide resolved

waspc/examples/todoApp/ensure_app_compiles_and_builds.sh Outdated Show resolved Hide resolved

waspc/data/Generator/templates/sdk/wasp/server/utils.ts Outdated Show resolved Hide resolved

cprecioso added 6 commits May 9, 2025 16:06

Simplify tsc command

2efe78a

Merge remote-tracking branch 'origin/main' into cprecioso/issue2384

fdbcda7

Ignore BigInt

5bfb400

Snapshots

2b2404c

Make auth properties optional

9c98ce4

Snapshots

fbf166e

sodic approved these changes May 9, 2025

View reviewed changes

cprecioso mentioned this pull request May 9, 2025

Update server tsconfig target #2735

Open

cprecioso merged commit 14fc39d into main May 9, 2025
5 checks passed

cprecioso deleted the cprecioso/issue2384 branch May 9, 2025 15:16

cprecioso mentioned this pull request May 12, 2025

In CI, check for TS errors in built server code (of example app) by running npx tsc #2384

Closed

In CI, check for TS errors in built server code (of example app) by running npx tsc #2672

In CI, check for TS errors in built server code (of example app) by running npx tsc #2672

Conversation

cprecioso commented Apr 15, 2025 • edited Loading

Select what type of change this PR introduces:

This comment was marked as outdated.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cprecioso Apr 29, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sodic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cprecioso commented Apr 29, 2025

infomiho commented Apr 29, 2025

infomiho left a comment

Choose a reason for hiding this comment

sodic left a comment

Choose a reason for hiding this comment

cprecioso commented May 6, 2025

sodic left a comment

Choose a reason for hiding this comment

sodic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

In CI, check for TS errors in built server code (of example app) by running `npx tsc` #2672

In CI, check for TS errors in built server code (of example app) by running `npx tsc` #2672

cprecioso commented Apr 15, 2025 •

edited

Loading

cprecioso Apr 29, 2025 •

edited

Loading