- Simplified Auth User API: Introduced a simpler API for accessing user auth fields (for example `username`, `email`, `isEmailVerified`) directly on the `user` object, eliminating the need for helper functions.
### ⚠️ Breaking Changes & Migration Guide
We had to make a couple of breaking changes to reach the new simpler API:
1. You don't need to use `getUsername` to access the username:
- Before: Used `getUsername` to access the username.
- After: Directly use `user.identities.username?.id`.
2. You don't need to use `getEmail` to access the email:
- Before: Used `getEmail` to access the email.
- After: Directly use `user.identities.email?.id`.
3. Better API for accessing `providerData`:
- Before: Required complex logic to access typed provider data.
- After: Directly use `user.identities.<provider>.<value>` for typed access.
4. Better API for accessing `getFirstProviderUserId`:
- Before: Used `getFirstProviderUserId(user)` to get the ID.
- After: Use `user.getFirstProviderUserId()` directly on the user object.
5. You don't need to use `findUserIdentity` any more:
- Before: Relied on `findUserIdentity` to check which user identity exists.
These changes improve code readability and lower the complexity of accessing user's auth fields. Follow the [detailed migration steps to update your project to 0.14.0](https://wasp-lang.dev/docs/migrate-from-0-13-to-0-14).
### Note on Auth Helper Functions (`getUsername`, `getEmail` etc.)
These changes only apply to getting auth fields from the `user` object you receive from Wasp, for example in the `authRequired` enabled pages or `context.user` on the server. If you are fetching the user and auth fields with your own queries, you _can_ keep using most of the helpers. Read more [about using the auth helpers](https://wasp-lang.dev/docs/auth/entities#including-the-user-with-other-entities).
- Improved how IDE auto-imports symbols from the `wasp` package. If you have an existing project, add these lines to your `tsconfig.json` to getter better IDE support:
Wasp 0.13.0 switches away from using Passport for our OAuth providers in favor of [Arctic](https://arctic.js.org/) from the [Lucia](https://lucia-auth.com/) ecosystem. This change simplifies the codebase and makes it easier to add new OAuth providers in the future.
This however, means that there are breaking changes in the way you define OAuth providers in your Wasp project.
Read the migration guide at https://wasp-lang.dev/docs/migrate-from-0-12-to-0-13 for more details.
- Wasp now supports defining the `WASP_SERVER_URL` environment variable and exposes it as `serverUrl` in the server config which can be imported from `wasp/server`.
- Wasp AI switched from GPT 3.5 Turbo 0613 to GPT 3.5 Turbo 0125, which gives it bigger context, ensuring generation doesn't fail for bigger apps, while also being cheaper.
If your project is using an older version of Wasp, you will want to check out the detailed migration instructions at https://wasp-lang.dev/docs/migrate-from-0-11-to-0-12 .
-`tsconfig.json`, `vite.config.ts`, and `public/` moved to the top dir.
- The server/client code separation is no longer necessary. You can now organize your code however you want, as long as it's inside the `src/` directory.
- All external imports in your Wasp file now must have paths starting with `@src` (e.g., `import foo from '@src/MainPage.jsx'`). The paths can no longer start with `@server` or `@client`.
Before 0.12.0, authentication in Wasp was based on the `User` model which the developer needed to set up properly and take care of the auth fields like `email` or `password`.
With 0.12.0, authentication is based on the auth models which are automatically set up by Wasp. You don't need to take care of the auth fields anymore, be it by adding them to the `User` model or by adding whole new entities like `SocialLogin`.
The `User` model is now just a business logic model and you use it for storing the data that is relevant for your app.
In the background, Wasp is now using [Lucia](https://github.com/lucia-auth/lucia) as the core auth library.
Operation (i.e., Queries and Actions) and Job names in `.wasp` files must now begin with a lowercase letter: `query getTasks {...}`, `job sendReport {...}`.
Entity names in `.wasp` files must now begin with an uppercase letter: `entity Foo {...}`.
- Multiple auth methods per single user are not allowed anymore (while before a user could first sign up with a social account and then add email/pass to it).
- Auth field customization is no longer possible using the `_waspCustomValidations` on the `User` entity.
These are both temporary regressions and will be replaced with better mechanisms in the future.
We relaxed that constraint so it now works with any Node version equal to or newer than the oldest LTS version that Wasp supports, meaning that now Wasp works with any Node version >= 18.
While so far it was available only through the https://usemage.ai , Wasp AI is now also available via the `wasp` CLI, enabling you to create a new Wasp app from nothing more than a title and a short description.
You can run it by picking AI as an option in the `wasp new` wizard, or via `wasp new:ai` which allows you to provide all the details via the command line (useful for more programmatic usage).
You need to provide your own OpenAI API token, but that also means you can choose which model to use for the code generation: e.g. you can use GPT-4 all the way, instead of the default GPT-4 + GPT-3 combo that https://usemage.ai uses.
### 🎉 [New Feature] Serving the Client From a Subdirectory
You can now serve the client from a subdirectory. This is useful if you want to serve the client from a subdirectory of your domain, e.g. `https://example.com/my-app/`.
To do this, you need to add the `client.baseDir` property to your `.wasp` file:
- Changed the minimum number of machines that a server app is using when deployed to Fly.io from 0 to 1. This prevents the server app from shutting down when there are no requests to it. There might be some other work that the server is doing e.g. running periodic Jobs or sending e-mails, so we want to make sure that the server is always running.
- Fixes a regression where a missing DB on the DB server would prevent project from running. Now, Wasp will tolerate the missing DB error and rely on Prisma to create the DB for you (like before).
- Fixed a bug with Prisma which prevent connections via SSL with our versions of Alpine and OpenSSL. We upgraded to the latest Prisma 4.X.X which fixes this issue.
### 🎉 [New Feature] Enable Customising the Vite Config
You can now customise the Vite config for your client app. This allows you to add plugins, change the dev server settings and more.
By adding a `vite.config.ts` or `vite.config.js` to your `client` directory, you can customise the Vite config. For example, you change the dev server behaviour
Running `wasp studio` in the root of your project starts Wasp Studio which visualises your application and shows you the relationships between pieces of your app. It is an experimental feature which is not yet fully ready, but we are working on it and will be adding more features to it in the future.
We added an API for extending the default signup form with custom fields. This allows you to add fields like `age`, `address`, etc. to your signup form.
You first need to define the `auth.signup.additionalFields` property in your `.wasp` file:
### 🎉 [New Feature] Support for PostgreSQL Extensions
Wasp now supports PostgreSQL extensions! You can enable them in your `main.wasp` file:
```wasp
app todoApp {
// ...
db: {
system: PostgreSQL,
prisma: {
clientPreviewFeatures: ["postgresqlExtensions"],
dbExtensions: [{
name: "pgvector",
// map: "vector", (optional)
// schema: "public", (optional)
// version: "0.1.0", (optiona)
}]
}
}
}
```
This will add the necessary Prisma configuration to your `schema.prisma` file. Keep in mind that your database needs to support the extension you want to use. For example, if you want to use the `pgvector` extension, you need to install it in your database first.
### 🎉 [New Feature] Added Typescript support for Jobs
Now you can type your async jobs better and receive all the benefits of Typescript. When you define a job, Wasp will generate a generic type which you can use to type your job function:
```wasp
job simplePrintJob {
executor: PgBoss,
perform: {
fn: import { simplePrint } from "@server/jobs.js",
Wasp now offers a way to link to pages in your app in a type-safe way. This means that you can't accidentally link to a page that doesn't exist, or pass the wrong arguments to a page.
After you defined your routes:
```wasp
route TaskRoute { path: "/task/:id", to: TaskPage }
```
You can get the benefits of type-safe links by using the `Link` component from `@wasp/router`:
- Default .gitignore that comes with new Wasp project (`wasp new`) is now more aggressive when ignoring .env files, ensuring they don't get committed by accident (wrong name, wrong location, ...).
When an external import is missing its implementation, waspls now offers a Code Action to quickly scaffold the missing JavaScript or TypeScript function:
```wasp
query getTasks {
fn: import { getTasks } from "@server/queries.js",
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// ERROR: `getTasks` is not exported from `src/server/queries.ts`
entities: [Task],
}
```
Using the code action (pressing <kbd>Ctrl</kbd> + <kbd>.</kbd> or clicking the lightbulb 💡 icon in VSCode) will add the following code to `src/server/queries.ts`:
- Wasp copied over the `.env.server` instead of `.env.client` to the client app `.env` file. This prevented using the `.env.client` file in the client app.
- waspls thought that importing `"@client/file.jsx"` could mean `"@client/file.tsx"`, which could hide some missing import diagnostics and cause go-to definition to jump to the wrong file.
Read all about Prisma preview features in [the official docs](https://www.prisma.io/docs/concepts/components/preview-features/client-preview-features).
- Wasp's **signup action**`import signup from '@wasp/auth/signup` now accepts only the user entity fields relevant to the auth process (e.g. `username` and `password`).
This ensures no unexpected data can be inserted into the database during signup, but it also means you can't any more set any user entity fields via signup action (e.g. `age` or `address`).
Instead, those should be set in the separate step after signup, or via a custom signup action of your own.
- Wasp now uses **React 18**! Check the following upgrade guide for details: https://react.dev/blog/2022/03/08/react-18-upgrade-guide .
The most obvious difference you might notice is that your `useEffect` hooks run twice on component mount.
This is due to the React 18's StrictMode, and it happens only during development, so it doesn't change the behaviour of your app in production.
For more details on StrictMode, check https://react.dev/reference/react/StrictMode .
Wasp now supports WebSockets! This will allow you to have a persistent, realtime connection between your client and server, which is great for chat apps, games, and more.
What's more, Wasp's WebSockets support full-stack type safety, so you can be sure that your client and server are communicating with strongly typed events.
Enable WebSockets in your project by adding the following to your `main.wasp` file:
```
app todoApp {
// ...
webSocket: {
fn: import { webSocketFn } from "@server/webSocket.js",
autoConnect: true, // optional, default: true
},
}
```
Then implement it on the server with optional types:
You can tell Wasp to automatically generate server-side logic (Queries and Actions) for creating, reading, updating, and deleting a specific entity. As you change that entity, Wasp automatically regenerates the backend logic.
We now offer an interactive way to create a new project. You can run `wasp new` and follow the prompts to create a new project. This is the recommended way to create a new project. It will ask you for the project name and to choose one of the starter templates.
- We changed some of the extensions on Wasp-provided imports from `.js` to `.ts`. For example `useAuth.js` is now `useAuth.ts`. Therefore, you should import them like this: `import useAuth from '@wasp/auth/useAuth'` (without the `.js` extension). Some other affected imports are `@wasp/auth/login.js`, `@wasp/auth/logout.js`, and similar.
You can now use e-mail authentication in your Wasp app! This means that users can sign up and log in using their e-mail address. You get e-mail verification and password reset out of the box.
Wasp now provides a set of UI components for authentication. You can use them to quickly build a login and signup page for your app. The UI changes dynamically based on your Wasp config.
We provide `LoginForm`, `SignupForm`, `ForgotPassworForm`, `ResetPasswordForm` and`VerifyEmailForm` components. You can import them from `@wasp/auth/forms` like:
Need a specific endpoint, like `/healthcheck` or `/foo/callback`? Or need complete control of the response? Use an `api` to define one by tying a JS function to any HTTP method and path! For example:
Wasp now supports sending e-mails! You can use the `emailSender` app property to configure the e-mail provider and optionally the `defaultFrom` address. Then, you can use the `send` function in your backend code to send e-mails.
```ts
// main.wasp
app MyApp {
emailSender: {
provider: SendGrid,
defaultFrom: {
name: "My App",
email: "myapp@domain.com"
},
},
}
// server/actions.ts
import { emailSender } from '@wasp/email/index.js'
### `wasp start db` -> Wasp can now run your dev database for you with a single command
Moving from SQLite to PostgreSQL with Wasp can feel like increase in complexity, because suddenly you have to care about running your PostgreSQL database, providing connection URL for it via env var, and if you checkout somebody's else Wasp project, or your old Wasp project that you have no memory of any more, you also have to figure all that out.
To help with that, we now added `wasp start db`, which runs a development database for you!
That it, all you need to do is run `wasp start db` and you are good to go. No env var setting, no remembering how to run the db.
By leveraging Vitest and some supporting libraries, Wasp now makes it super easy to add unit tests and React component tests to your frontend codebase.
- Starts the process of removing the coupling between `usernameAndPassword` and social logins. Now, your `userEntity` no longer requires a `username` or `password` field if you only want to use Google/GitHub for auth.
- All client files which use `JSX` need to have either the `.jsx` or the `.tsx` extension. This is because we now use `Vite` under the hood instead of `Create React App`, and `Vite` requires these extensions to be present to process `JSX`` properly.
- The Tailwind and PostCSS config files need to have the `.cjs` extension. These config files are CommonJS modules, and with `Vite` we are using ES modules by default.
### Wasp now uses Vite instead of Create React App
We moved away from using Create React App for the client app. This means that dev startup time will be much faster and we are following the latest best practices for building web apps with React.
Wasp now passes in a context to the server `setupFn` that contains Express `app` and http `server` objects. This can be used as an escape hatch for things like custom routes or WebSocket support.
- The Dockerfile has been updated to build the server files during the Docker build stage instead of during server startup. This will reduce the memory footprint required for running apps.
You can now define a root component for your client app. This is useful if you want to wrap your app in a provider or have a common layout. You can define it in `app.client.rootComponent` in your `.wasp` file.
We have made it much easier to deploy your Wasp apps via a new CLI command, `wasp deploy`. 🚀 This release adds support for Fly.io, but we hope to add more hosting providers soon!
We are removing the requirement for a specific npm version to enable following the Node.js LTS releases (Node.js LTS releases sometimes bump the major `npm` version).
We are still requiring Node.js to be version 18, but the `npm` version can be anything and for most of Wasp users it will be the version that comes with Node.js.
We have added GitHub as another social login option. It is as easy to use as Google, and only requires adding `gitHub` to your `app.auth.methods` plus two environment variables (`GITHUB_CLIENT_ID` and `GITHUB_CLIENT_SECRET`)! Check out the docs for more.
- The CLI command for applying a migration with a name has changed from `wasp db migrate-dev foo` to `wasp db migrate-dev --name foo`. This allowed us to add more flags, like `--create-only`.
- Again fixed Dockerfile generated with `wasp build` (after fixing it only half-way last time :facepalm) -> Prisma would break due to unsupported version of openssl.
- Updates Create React App from version 4.0.3 to 5.0.1. This brings many improvements as well as downstream library updates. It also has a list of possible breaking changes: https://github.com/facebook/create-react-app/blob/main/CHANGELOG.md
- Updates Prisma from version 3.15.2 to 4.5.0. Please check out their upgrade guide: https://www.prisma.io/docs/guides/upgrade-guides/upgrading-versions/upgrading-to-prisma-4 and release notes: https://github.com/prisma/prisma/releases for any possible breaking changes.
- Updates required Node LTS version from version 16 to version 18. This Node ecosystem change happened on 2022-10-25: https://github.com/nodejs/Release
2. Rename your project's root directory to something like `foo_old`
3. Create a new project by running `wasp new foo`
4. Copy all server-side code from `foo_old/ext` to `foo/src/server`
5. Copy all client-side code from `foo_old/ext` to `foo/src/client`
6. Copy all shared code (if any) from `foo_old/ext` to `foo/src/shared` and
adapt imports in files that reference it:
- For example, `import bar from './bar.js'` becomes `import bar from "../shared/bar.js"`
7. Copy all lines you might have added to `foo_old/.gitignore` into
`foo/.gitignore`
8. Finally, copy `foo_old/main.wasp` to `foo/main.wasp` and correct external
imports: - Queries, Actions, Jobs, and the Server setup function must import their code from `@server` - Pages and the Client setup function must import their code from `@client`
For example, if you previously had something like:
```js
page LoginPage {
// This previously resolved to ext/LoginPage.js
component: import Login from "@ext/LoginPage.js"
}
// ...
query getTasks {
// This previously resolved to ext/queries.js
fn: import { getTasks } from "@ext/queries.js",
}
```
You should change it to:
```js
page LoginPage {
// This resolves to src/client/LoginPage.js
component: import Login from "@client/LoginPage"
}
// ...
query getTasks {
// This resolves to src/server/queries.js
fn: import { getTasks } from "@server/queries.js",
}
```
Do this for all external imports in your `.wasp` file. After you're done, there shouldn't be any occurences of the string `"@ext"`.
You can now customize the default Wasp Dockerfile by either extending/replacing our build stages or using your own custom logic. To make use of this feature, simply add a Dockerfile to the root of your project and it will be appended to the bottom of the existing Wasp Dockerfile.
- The `EmailAndPassword` auth method has been renamed `usernameAndPassword` to better reflect the current usage. Email validation will be addressed in the future.
- NOTE: If you simply changed `email` to `username` in your .wasp file, Prisma will try to drop the table and recreate it, which is likely not what you want if you have data you want to preserve.
- If you would like to add a new `username` column and keep `email` as is, be sure to add a calculated value in the migration (perhaps a random string, or something based on the `email`). The `username` column should remain `NOT NULL` and `UNIQUE`.
-`WASP_WEB_CLIENT_URL` is now a required environment variable to improve CORS security. It is set by default in development. In production, this should point to the URL where your frontend app is being hosted.
- The generated Dockerfile has been updated from `node:14-alpine` to `node:16-alpine`.
- Wasp Jobs callback function arguments have been updated to the following: `async function jobHandler(args, context)`. Jobs can now make use of entities, accessed via `context`, like Operations. Additionally, the data passed into the Job handler function are no longer wrapped in a `data` property, and are now instead accessed exactly as they are supplied via `args`.
### [NEW FEATURE] Google is now a supported authentication method!
You can now offer your users the ability to sign in with Google! Enabling it is just a few lines and offers a fast, easy, and secure way to get users into your app! We also have a comprehensive setup guide for creating a new app in the Google Developer Console.
Stay tuned, as more external auth methods will be added in the future. Let us know what you'd like to see support for next!
Now, your installation of Wasp also brings Wasp language server with it! This means live error reporting in Wasp files in supported IDEs (currently only VSCode).
Make sure to update your Wasp VSCode extension to get the benefits of Wasp Language Server.
### [NEW FEATURE] Optimistic updates via useAction hook
We added `useAction` hook to our JS API, which allows you to specify optimistic update details for an Action.
This means that, if you have a good idea of how an Action will affect the state on the client, you can perform those changes immediatelly upon its call (instead of waiting for Action to finish), by modifying what specific Queries currently return.
Once Action is actually done, related Queries will be unvalidated as usual and therefore fetch the real result, but in the meantime the changes you specified via optimistic updates will be visible.
This is great for apps where there is a lot of interactivity and you want the UI to update instantly with your changes, even as they are still being saved to the server.
Check out https://wasp-lang.dev/docs/language/features#the-useaction-hook for more details.
- Works around a `sodium-native` bug (used by a Wasp dependency, `secure-password`) that caused signup/login runtime issues with Heroku deployments by downgrading it from v3.4.1 to v3.3.0 via a `package.json` override. Ref: https://github.com/sodium-friends/sodium-native/issues/160
Among various other things, this brins support for OpenSSL3. So if you couldn't run Wasp on your operating system due to Prisma not supporting OpenSSL3, those days are over!
### [NEW FEATURE] Wasp now has support for running Jobs!
If you have server tasks that you do not want to handle as part of the normal request-response cycle, now Wasp allows you to make that function a Job and it will gain some "superpowers"!
Jobs will persist between server restarts, can be retried if they fail, and they can even be delayed until the future (or have a recurring schedule)!
Some examples where you may want to use a Job on the server include sending an email, making an HTTP request to some external API, or doing some nightly calculations.
To run Jobs, you don't need any additional infrastructure at the moment, just a Postgre database that you anyway need to deploy Wasp to production.
### BREAKING CHANGES
- Wasp now requires latest LTS version of NodeJS
- We had a bit of issues with being too relaxed on the version of NodeJS that can be used with Wasp so we thightened it up a bit.
We also added a more thorough check in Wasp for it, that will warn you very explicitely if you are using the wrong version of Node.
- Updated react-query to v3
- This brings some new features from react query while also laying the foundation for the further features we are building on top of it in Wasp (coming soon!).
- Updated python to python3 in Dockerfile generated upon `wasp build`.
### Various improvements
- Finally fixed a bug with orphaned processes in development.
- Various other bug fixes, doc improvements, and refactorings.
### [BREAKING CHANGE] Upgrading Prisma to version 3.9.1
We are happy to announce Wasp is now using a much newer version of Prisma! This change does not impact the Wasp DSL support for Prisma, but it does come with some caveats from Prisma based on your usage. Please see this note for any breaking changes: https://www.prisma.io/docs/guides/upgrade-guides/upgrading-versions/upgrading-to-prisma-3
_Note: When you first migrate after upgrading, you will likely see a new migration created for 3.x specific features related to updating foreign keys and indexes._
