Rework SDK and user `tsconfig.json` for optimal DX #2656

sodic · 2025-04-14T11:37:03Z

Fixes #2258
Fixes #2259
Fixes #1986

I commented all the changes and tested it with waspc/examples/todoApp (both in dev and production).

Todo:

Update migration guide
Update changelog
Update starters: Update tsconfig and vite-env.d.ts open-saas#419
Update Open Saas: Update starters with tsconfig changes starters#24

Offspring issues with future work:

sodic

Left some elaborating comments.

sodic · 2025-04-14T11:40:39Z

waspc/data/Cli/templates/skeleton/tsconfig.json

I was thinking of moving these elaborating comments to Generator/ExternalConfig/TsConfig.hs.

Pros:

User TS config is less noisy.

I can write longer comments.

Cons:

Curious users won't get insight into why we choose specific properties.

@infomiho @cprecioso What do you guys think?

No strong opinion, IIUC users are not expected/allowed to modify the tsconfig, so it shouldn't matter. If foresee users able to modify some keys, then I'd keep the comments on those.

I don't think the majority of users read this config file and its comments. I'm okay with moving the comments into Haskell - for our sake so we know why we did what we did.

One extra option be to move the comments and then link to the Haskell file on github.com where the comments live for the curious power users.

I moved them to Haskell but didn't include the link to the Haskell source. I don't think it's necessary after all

sodic · 2025-04-14T11:42:35Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

-    "esModuleInterop": true,
-    "moduleResolution": "node",
-    "outDir": "dist",
+    "skipLibCheck": true,


No change here, skipLibCheck was just moved.

sodic · 2025-04-14T11:44:07Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

  "compilerOptions": {
+    /* Basic opitions */


I kicked out the "extends": "@tsconfig/node{= majorNodeVersion =}/tsconfig.json":

We're not building for node, we're primarily working with a bundler. See Bundle the SDK together with the server #2493

I wanted us to have explicit control over all the options (instead of overriding some of them).

Great change, we are more self reliant and we don't have to worry about version bumps causing weird side effects. We do need to keep in mind to stay up to date with the best practices for the tsconfig.json over time 👍

sodic · 2025-04-14T11:48:17Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+    "rootDir": ".",
+    "outDir": "dist", 


No change here:

rootDir was implicitly set to ".". I just made it explicit.

outDir field was just moved.

sodic · 2025-04-14T11:49:19Z

waspc/data/Cli/templates/skeleton/tsconfig.json

    // Needed because this is used as a project reference.
    "composite": true,
-    "target": "esnext",
+    "target": "es2022",


Changed from es2017 to es2022. We're controlling the entire environment, so I set the this to the newest possible non-moving compilation target.

I'd actually say here esnext because we don't want TypeScript to be handling downleveling the code at all, right? Since Vite is the one that will be handling it for us, we don't want TypeScript to be complaining about it.

You are right, yes. I'll change it up :)
I'll do the same thing for module as well (since TS is the one processing this code before the bundler).

sodic · 2025-04-14T11:55:57Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+    /*
+      The `incremental` option enables faster SDK compilation, less Vite HMR
+      messages and it prevent unnecessary full-page reloads when using Vite HMR.
+      While this is great, we still want to dig deeper at some point to understand
+      better why Vite HMR misbehaves when the SDK is recompiled:
+      https://github.com/wasp-lang/wasp/issues/1934 
+    */


Only formatting.

sodic · 2025-04-14T11:56:54Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+    "rootDir": ".",
+    "outDir": "dist", 
+
+    /* Strictness and type checking */


To the reviewers: you should be able to understand all the fields/decisions from either:

The field's name

The in-file comments.

The mentioned issues.

If you don't, then the comments aren't good enough :)

So please let me know what I should add!

sodic · 2025-04-14T12:00:46Z

waspc/data/Cli/templates/skeleton/tsconfig.json

+    // Prevent features that don't work with transpilers (e.g., const enums)
+    "isolatedModules": true,
+    "moduleDetection": "force",


I only changed module and target and added isolatedModules and moduleDetection.

I could write a longer comment here (but it's probably too long to keep in user's tsconfig.json). One more reason to move them to Haskell.

Check this out for the changes in this file: https://www.totaltypescript.com/tsconfig-cheat-sheet

TypeScript recently shipped a flag that includes these changes: erasableSyntaxOnly

https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option

Hm, I belive that option does more stuff than just being a shorthand for these two fields (e.g., it removes enums altogether).

We need isolatedModules to correctly model our code's current behavior. TS currently doesn't warn about these casees and they break in runtime.
That's not the case for erasableSyntaxOnly so I wouldn't force it on our users yet (our code works fine with non-erasable syntax).

The erasableSyntaxOnly setting also typically relies on verbatimModuleSyntax being set to true, which I'm also not sure I'd do right away (since it forces type imports/exports). Let's discuss that one here: #2657

You say

I only changed module and target

but I don't see those changes in this diff?

I changed them back based on this comment: #2656 (comment)

sodic · 2025-04-14T12:02:05Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

  "compilerOptions": {
+    /* Basic opitions */
+    "target": "es2022",


Same story as in skeleton/tsconfig.json.

sodic · 2025-04-14T12:17:31Z

waspc/examples/todoApp/tsconfig.json

This is just a copy of the new skeleton/tsconfig.json.

sodic · 2025-04-14T12:22:42Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+    "strict": true,
+    "useUnknownInCatchVariables": false, 
+    "noImplicitAny": false,
+    "strictPropertyInitialization": false,
+    // The following two properties are disabled because we don't
+    // yet want to force user code to use them.
+    // Reference: https://github.com/wasp-lang/wasp/issues/2655
+    "noUncheckedIndexedAccess": false,
+    "noImplicitOverride": false,


There are no meaningful changes here, I just flipped things around. Instead of setting strict to false and then activate the flags can use, we now set strict to true and deactivate the flags we can't use.

Isn't noUncheckedIndexedAccess and noUncheckedIndexedAccess false by default? Even with strict?
Is this more of a documentation to signal we want to change those in future?

Isn't noUncheckedIndexedAccess and noUncheckedIndexedAccess false by default?

They are, yes

Is this more of a documentation to signal we want to change those in future?

Also yes. I could remove them though since we have the issue.

You have more context about that here. Up to you.

I kept them in the end.

sodic · 2025-04-14T12:24:05Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+    "declaration": true, // Allows users to consume the SDK as a library, enables autocomplete
+    "declarationMap": true, // Makes go-to-defintion go to source instead of type definitios
+    "sourceMap": true, // Needed for debugging


sourceMap and declaration are just moved. declarationMap is new and fixes #1986

cprecioso · 2025-04-14T13:10:01Z

waspc/data/Cli/templates/skeleton/tsconfig.json

+    // Prevent features that don't work with transpilers (e.g., const enums)
+    "isolatedModules": true,
+    "moduleDetection": "force",


TypeScript recently shipped a flag that includes these changes: erasableSyntaxOnly

https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option

cprecioso · 2025-04-14T13:11:56Z

waspc/data/Cli/templates/skeleton/tsconfig.json

    // Needed because this is used as a project reference.
    "composite": true,
-    "target": "esnext",
+    "target": "es2022",


I'd actually say here esnext because we don't want TypeScript to be handling downleveling the code at all, right? Since Vite is the one that will be handling it for us, we don't want TypeScript to be complaining about it.

cprecioso · 2025-04-14T13:18:20Z

waspc/data/Cli/templates/skeleton/tsconfig.json

+      // NOTE: Overriding `typeRoots` prevents TS from climbing up the file
+      // tree and including `node_modules/@types` from parent folders.


Mmm I'd try to add
import "@testing-library/jest-dom"; in vite-env.d.ts and I think we'd avoid doing stuff in typeRoots

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

infomiho · 2025-04-15T11:53:58Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+      Since we can't have "bundler", "node10" is the next best thing.
+      Source: https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution
+
+      TODO: Change "moduleResolution" to "bundler" when we move away from stitches.


I'd bump the priority on moving away from Stitches #1565

infomiho · 2025-04-15T11:55:47Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+    /*
+      User code was compiled uses `"strict": true`, so we know we can use it
+      here as well. We override some of strict's options because parts of the SDK
+      code don't respec them. This only makes the SDK ruleset more permissive than


Suggested change

code don't respec them. This only makes the SDK ruleset more permissive than

code don't respect them. This only makes the SDK ruleset more permissive than

infomiho · 2025-04-15T11:57:25Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

+    // The following two properties are disabled because we don't
+    // yet want to force user code to use them.
+    // Reference: https://github.com/wasp-lang/wasp/issues/2655


Nitpick: Let's use block comment style to make the comment style uniform.

infomiho · 2025-04-15T12:00:24Z

waspc/examples/todoApp/src/vite-env.d.ts

+// This is needed to properly support Vitest testing with jest-dom matchers.
+// Types for jest-dom are not recognized automatically and Typescript complains
+// about missing types e.g. when using `toBeInTheDocument` and other matchers.
+import '@testing-library/jest-dom'


This is a "breaking change" for users to be able to use Vitest again? Our starter templates should include this line as well then.

Nice catch!

Done:

Update starters with tsconfig changes starters#24

Update tsconfig and vite-env.d.ts open-saas#419

infomiho · 2025-04-15T12:01:56Z

waspc/examples/todoApp/tsconfig.json

@@ -17,26 +17,25 @@
    // We're bundling all code in the end so this is the most appropriate option,


It would be nice if we could come up with a way for Wasp CLI to "upgrade" the tsconfig.json when it's broken for users e.g. set the correct values after validation catches issues. That would make these kind of changes much more palatable. It's not terrible, but maybe we can play around with that.

Interesting idea, care to create a mr. issue?

Will do 👍

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

infomiho · 2025-04-15T12:05:10Z

I love the jump to definition behavior change 👍

sodic · 2025-04-16T22:54:26Z

waspc/ChangeLog.md

@@ -3,12 +3,27 @@
 ## Unreleased

 ### ⚠️ Breaking Changes
+Address all breaking changes by following [the official migration guide](https://wasp.sh/docs/migration-guides/migrate-from-0-16-to-0-17). This is just a short overview:


Will become a valid link once we release.

Suggested change

Address all breaking changes by following [the official migration guide](https://wasp.sh/docs/migration-guides/migrate-from-0-16-to-0-17). This is just a short overview:

Follow the [the official migration guide](https://wasp.sh/docs/migration-guides/migrate-from-0-16-to-0-17) to address all the breaking changes. Here's a short overview:

sodic · 2025-04-16T23:07:24Z

web/docs/general/wasp-ts-config.md

-    ```
-
+1. Go into the Wasp project you want to switch to the Wasp TS config (or create a new Wasp project if you want to try it out like that). Make sure you are on Wasp >= 0.16.3 and your project is working.
+2. Rename `tsconfig.json` file to `tsconfig.src.json`


Wasp >= 0.16.0 validates their configs have include properly set up.

sodic · 2025-04-16T23:08:04Z

web/docs/general/wasp-ts-config.md

-:::caution Requires Wasp >= 0.15
-This document assumes your app works with Wasp >= 0.15.  
-If you haven't migrated your app yet, follow the [migration instructions](../migration-guides/migrate-from-0-14-to-0-15.md) and verify everything works. After that, come back here and try out the new Wasp TS config.
+:::caution Requires Wasp >= 0.16.3


I bumped this up since we made a change in the public API with 0.16.3 (HttpRoute by @FranjoMindek).

sodic · 2025-04-16T23:10:56Z

waspc/src/Wasp/Generator/ExternalConfig/TsConfig.hs

+  -- References for understanding the required compiler options:
+  --   - The comments in templates/sdk/wasp/tsconfig.json
+  --   - https://www.typescriptlang.org/docs/handbook/modules/introduction.html
+  --   - https://www.totaltypescript.com/tsconfig-cheat-sheet
+  --   - https://www.typescriptlang.org/tsconfig/
  concat
    [ validateRequiredFieldInCompilerOptions "module" T._module "esnext",
      validateRequiredFieldInCompilerOptions "target" T.target "esnext",
+      -- Since Wasp ends up bundling the user code, `bundler` is the most
+      -- appropriate `moduleResolution` option.
      validateRequiredFieldInCompilerOptions "moduleResolution" T.moduleResolution "bundler",
+      validateRequiredFieldInCompilerOptions "moduleDetection" T.moduleDetection "force",
+      -- `isolatedModules` prevents users from using features that don't work
+      -- with transpilers and would fail when Wasp bundles the code with rollup
+      -- (e.g., const enums)
+      validateRequiredFieldInCompilerOptions "isolatedModules" T.isolatedModules True,
      validateRequiredFieldInCompilerOptions "jsx" T.jsx "preserve",
      validateRequiredFieldInCompilerOptions "strict" T.strict True,
      validateRequiredFieldInCompilerOptions "esModuleInterop" T.esModuleInterop True,
      validateRequiredFieldInCompilerOptions "lib" T.lib ["dom", "dom.iterable", "esnext"],
      validateRequiredFieldInCompilerOptions "allowJs" T.allowJs True,
-      validateRequiredFieldInCompilerOptions "typeRoots" T.typeRoots ["node_modules/@testing-library", "node_modules/@types"],
+      -- Wasp internally uses TypeScript's project references to compile the
+      -- code. Referenced projects may not disable emit, so we must specify an
+      -- `outDir`.
      validateRequiredFieldInCompilerOptions "outDir" T.outDir ".wasp/out/user",
+      -- The composite flag is required because Wasp uses project references
+      -- (i.e., web app and server reference user code as a subproject)


These comments were moved from user's tsconfig.json and expanded.

sodic · 2025-04-16T23:11:53Z

waspc/data/Cli/templates/skeleton/tsconfig.json

I moved them to Haskell but didn't include the link to the Haskell source. I don't think it's necessary after all

cprecioso

LGTM, leaving it approved, added some nitpicky comments about phrasing but code-wise is good

cprecioso · 2025-04-22T13:18:30Z

waspc/ChangeLog.md

+  ```json
+  {
+    "compilerOptions": {
+      // ...
+      "moduleDetection": "force",
+      "isolatedModules": true,
+      // Remove 'typeRoots'
+    },
+  }
+  ```


I'd rather express this as a diff, it renders nicely:

Suggested change

```json

{

"compilerOptions": {

// ...

"moduleDetection": "force",

"isolatedModules": true,

// Remove 'typeRoots'

},

}

```

```diff

{

"compilerOptions": {

+ "moduleDetection": "force",

+ "isolatedModules": true,

- "typeRoots": [ ... ]

},

}

```

cprecioso · 2025-04-22T13:19:00Z

waspc/ChangeLog.md


 - In the `usernameAndPassword` authentication method, the function `login()` imported from `wasp/client/auth` now accepts an object with `username` and `password` instead of two separate arguments ([#2598](https://github.com/wasp-lang/wasp/pull/2598))
+- We've made some improvements to our TypeScript setup that require you to update the `tsconfig.json` file. The migration guide will lead you through them.
+  For posterity, here are all the non-cosmetic changes we've made:


Nitpick: everything in the changelog is for posterity 😂

Suggested change

For posterity, here are all the non-cosmetic changes we've made:

Here are the non-cosmetic changes we made:

Haha, fair enough!

cprecioso · 2025-04-22T13:23:53Z

waspc/ChangeLog.md

+    },
+  }
+  ```
+- [The issue](https://github.com/testing-library/jest-dom/issues/546#issuecomment-1889884843) with `jest-dom` types is now addressed in `src/vite-env.d.ts`.


This entry is not very understandable for users I think, especially since it links to an issue in another project altogether, and the error it describes is not one our users were having (because we were already solving it).

I'd go for something along the lines of

Suggested change

- [The issue](https://github.com/testing-library/jest-dom/issues/546#issuecomment-1889884843) with `jest-dom` types is now addressed in `src/vite-env.d.ts`.

- The types for DOM helpers in tests are now imported from `src/vite-env.d.ts` instead of changing the `tsconfig.json`'s `typeRoots`.

(and I'm sure it can be improved further 😅)

cprecioso · 2025-04-22T13:25:16Z

waspc/ChangeLog.md


 ### 🔧 Small improvements

 - Show a friendlier error when there are no routes defined in the wasp file ([#2643](https://github.com/wasp-lang/wasp/pull/2643))
+- Better TypeScript support ([#2656](https://github.com/wasp-lang/wasp/pull/2656))


Let's be specific

Suggested change

- Better TypeScript support ([#2656](https://github.com/wasp-lang/wasp/pull/2656))

- Modernized our TypeScript configuration and added support for jump-to-definition ([#2656](https://github.com/wasp-lang/wasp/pull/2656))

cprecioso · 2025-04-22T13:25:38Z

waspc/data/Cli/templates/skeleton/src/vite-env.d.ts

+// Types for jest-dom are not recognized automatically and Typescript complains
+// about missing types e.g. when using `toBeInTheDocument` and other matchers.
+// Reference: https://github.com/testing-library/jest-dom/issues/546#issuecomment-1889884843
+import '@testing-library/jest-dom'


letss gooooo 🔥

cprecioso · 2025-04-22T13:26:51Z

waspc/data/Generator/templates/sdk/wasp/tsconfig.json

  "compilerOptions": {
+    /* Basic opitions */


Suggested change

/* Basic opitions */

/* Basic options */

cprecioso · 2025-04-22T13:28:25Z

web/docs/migration-guides/migrate-from-0-16-to-0-17.md

@@ -104,7 +104,68 @@ It is possible that you were not using this function in your code.
 If you're instead using [the `<LoginForm>` component](../auth/ui.md#login-form),
 this change is already handled for you.

-### 2. Enjoy your updated Wasp app
+### Update your `tsconfig.json`


Suggested change

### Update your `tsconfig.json`

### 2. Update your `tsconfig.json`

cprecioso · 2025-04-22T13:30:03Z

web/docs/migration-guides/migrate-from-0-16-to-0-17.md

+new version of the file and reapplying them.
+
+Here's the new version `tsconfig.json`:
+```json title=tsconfig.json


I seem to remember you can use ```jsonc so that comments are supported? Maybe you can try it

Tried it, doesn't work. But json renders comments normally in docusaurus so it doesn't matter:

infomiho · 2025-04-22T20:16:56Z

web/docs/migration-guides/migrate-from-0-16-to-0-17.md

+the case for most users), just replace its contents with the new version shown
+below.
+
+If you have made changes to your `tsconfig.json` file, we recommend taking the


It would be really awesome if we could "fix" the errors in the tsconfig for the users. I know I'm repeating myself but I'm lobbying for the change at some point in the future 😂

I'll repeat myself too :D

#2656 (comment)

infomiho · 2025-04-22T20:17:39Z

web/docs/migration-guides/migrate-from-0-16-to-0-17.md

+```
+
+### 3. Tell Wasp about `jest-dom` types
+If you're using (or planning to use) Wasp's [client tests](../project/testing.md) with `jest-dom`,


Suggested change

If you're using (or planning to use) Wasp's [client tests](../project/testing.md) with `jest-dom`,

If you're using Wasp's [client tests](../project/testing.md) with `jest-dom`,

IMHO no need to anticipate every scenario with the sentence

I decided to keep it. I'd like to scare the reader into thinking "Well, I'm not using it but I don't want to give up on the idea" and doing the update. We'll have fewer discord support questions this way.

infomiho · 2025-04-22T20:18:19Z

web/docs/migration-guides/migrate-from-0-16-to-0-17.md

+```ts
+// This is needed to properly support Vitest testing with jest-dom matchers.
+// Types for jest-dom are not recognized automatically and Typescript complains
+// about missing types e.g. when using `toBeInTheDocument` and other matchers.
+// Reference: https://github.com/testing-library/jest-dom/issues/546#issuecomment-1889884843
+import '@testing-library/jest-dom'
+```


For better copy pastebility, I'd put the full contents they can just copy paste (99% users didn't change their vite-env.d.ts file)

sodic added 9 commits April 11, 2025 16:47

Clean up SDK tsconfig.json

0848749

Add explicity root dir

451a2c7

Update tsconfig options for user and the SDK

0f81d71

Update the targets to es2022

9a82fb8

Add validation for es2022 and elaborate typeRoots

07d0780

Improve some comments

5258eff

Update todoApp tsconfig to fit skeleton

09fe08a

Remove extra space

6d4ad9b

Improve comments in SDK tsconfig

ac417bd

sodic commented Apr 14, 2025

View reviewed changes

Add fullstop to comment

7f96dec

sodic commented Apr 14, 2025

View reviewed changes

cprecioso reviewed Apr 14, 2025

View reviewed changes

sodic added 4 commits April 14, 2025 15:36

Change module and target to esnext

779a08a

Change ts config validation to account for esnext

52f484a

Update todoApp tsconfig to fit skeleton

b3b0a87

Fix typos

813f74e

Martinsos requested a review from infomiho April 14, 2025 14:18

Remove typeRoots fix for jest-dom in favor of vite-env.d.ts

e4f869a

infomiho reviewed Apr 15, 2025

View reviewed changes

FranjoMindek reviewed Apr 15, 2025

View reviewed changes

waspc/data/Generator/templates/sdk/wasp/tsconfig.json Outdated Show resolved Hide resolved

FranjoMindek added refactoring Keeping that code clean! dx labels Apr 16, 2025

sodic added 2 commits April 16, 2025 23:45

Address review comments and fix formatting

35ee181

Merge branch 'main' into filip-sdk-tsconfig

9889566

sodic added 6 commits April 17, 2025 00:44

Move explanations from tsconfig.json to Haskell

f4a579d

Update the docs where appropriate

9d31a9e

Update Changelog and docs with vite-env.d.ts stuff

4e06f7f

Change file type in docs

a6c41e2

Change code snippet language in docs

7222082

Update skeleton vite-env.d.ts

9eceb0b

sodic commented Apr 16, 2025

View reviewed changes

This was referenced Apr 16, 2025

Update starters with tsconfig changes wasp-lang/starters#24

Merged

Update tsconfig and vite-env.d.ts wasp-lang/open-saas#419

Open

sodic added 2 commits April 17, 2025 01:30

Remove @tsconfig/node from SDK dependencies

a505f50

Remove comments from skeleton/tsconfig.json

a22ad9f

sodic force-pushed the filip-sdk-tsconfig branch from 725aaea to a22ad9f Compare April 17, 2025 00:03

sodic added 3 commits April 17, 2025 02:04

Remove trailing spaces

79d819e

Update e2e tests

e1b4cc2

Add one more thing to changelog

19366b5

sodic force-pushed the filip-sdk-tsconfig branch from 19366b5 to 79d819e Compare April 17, 2025 00:14

FranjoMindek assigned sodic Apr 18, 2025

cprecioso approved these changes Apr 22, 2025

View reviewed changes

infomiho reviewed Apr 22, 2025

View reviewed changes

sodic added 3 commits April 23, 2025 12:43

Address review changes

c5f5a47

Merge branch 'main' into filip-sdk-tsconfig

e28fedc

Update e2e tests

2999a7d

infomiho approved these changes Apr 23, 2025

View reviewed changes

Update e2e tests

ace43a7

sodic merged commit db7c774 into main Apr 23, 2025
6 checks passed

sodic deleted the filip-sdk-tsconfig branch April 23, 2025 12:16

This was referenced May 21, 2025

Update server/tsconfig.json to follow best practices for an app #2776

Open

Update web-app/tsconfig.json to follow best practices for an app #2777

Open

		// NOTE: Overriding `typeRoots` prevents TS from climbing up the file
		// tree and including `node_modules/@types` from parent folders.

	code don't respec them. This only makes the SDK ruleset more permissive than
	code don't respect them. This only makes the SDK ruleset more permissive than

		@@ -17,26 +17,25 @@
		// We're bundling all code in the end so this is the most appropriate option,

	Address all breaking changes by following [the official migration guide](https://wasp.sh/docs/migration-guides/migrate-from-0-16-to-0-17). This is just a short overview:
	Follow the [the official migration guide](https://wasp.sh/docs/migration-guides/migrate-from-0-16-to-0-17) to address all the breaking changes. Here's a short overview:

	For posterity, here are all the non-cosmetic changes we've made:
	Here are the non-cosmetic changes we made:

	- [The issue](https://github.com/testing-library/jest-dom/issues/546#issuecomment-1889884843) with `jest-dom` types is now addressed in `src/vite-env.d.ts`.
	- The types for DOM helpers in tests are now imported from `src/vite-env.d.ts` instead of changing the `tsconfig.json`'s `typeRoots`.

	- Better TypeScript support ([#2656](https://github.com/wasp-lang/wasp/pull/2656))
	- Modernized our TypeScript configuration and added support for jump-to-definition ([#2656](https://github.com/wasp-lang/wasp/pull/2656))

	### Update your `tsconfig.json`
	### 2. Update your `tsconfig.json`

	If you're using (or planning to use) Wasp's [client tests](../project/testing.md) with `jest-dom`,
	If you're using Wasp's [client tests](../project/testing.md) with `jest-dom`,

Uh oh!

Rework SDK and user tsconfig.json for optimal DX #2656

Rework SDK and user tsconfig.json for optimal DX #2656

Uh oh!

Conversation

sodic commented Apr 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sodic left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cprecioso Apr 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sodic Apr 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sodic Apr 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sodic Apr 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

infomiho Apr 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Rework SDK and user `tsconfig.json` for optimal DX #2656

Rework SDK and user `tsconfig.json` for optimal DX #2656

sodic commented Apr 14, 2025 •

edited

Loading

cprecioso Apr 15, 2025 •

edited

Loading

sodic Apr 14, 2025 •

edited

Loading

sodic Apr 14, 2025 •

edited

Loading

sodic Apr 14, 2025 •

edited

Loading

infomiho Apr 15, 2025 •

edited

Loading

infomiho Apr 15, 2025 •

edited

Loading

infomiho Apr 15, 2025 •

edited

Loading