Releases: wasp-lang/wasp
v0.8.2
Non-breaking Changes
- 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.
Bug fixes
- Fixed a file lock error that kills CLI when changing entities with
wasp start
running on newer Macs.
Support for defining the web app's root component
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.
wasp deploy
CLI command added
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!
Importable Wasp Entity types (on frontend and backend)
You can now import and use the types of Wasp entities anywhere in your code.
Let's assume your Wasp file contains the following entity:
entity Task {=psl
id Int @id @default(autoincrement())
description String
isDone Boolean @default(false)
user User @relation(fields: [userId], references: [id])
userId Int
psl=}
Here's how you can access and use its type in a backend file:
import { Task } from '@wasp/entities/Task'
const getTasks = (args, context) => {
const tasks: Task[] = // ...
// ...
}
And here's how you can to the same in a frontend file:
// ...
import { useQuery } from '@wasp/queries'
import getTasks from '@wasp/queries/getTasks.js'
import { Task } from '@wasp/entities'
type TaskPayload = Pick<Task, "id">
const Todo = (props: any) => {
// The variable 'task' will now have the type Task.
const { data: task } = useQuery<TaskPayload, Task>(getTask, { id: taskId })
// ...
}
Automatically generated types for Queries and Actions
Wasp now automatically generates appropriate types for the operations specified
in your .wasp
file. This reduces duplication and eliminates possible errors
(i.e., no way to specify incorrect entities). Assuming your .wasp
file looks
like this:
query getTasks {
fn: import { getTasks } from "@server/queries.js",
entities: [Task]
}
You'll get the following feature:
import { Task } from '@wasp/entities'
import { GetTasks} from '@wasp/queries/types'
type Payload = Pick<Task, 'isDone'>;
// Use the type parameters to specify the Query's argument and return types.
const getTasks: GetTasks<Payload, Task[]> = (args, context) => {
// Thanks to the definition in your `.wasp` file, the compiler knows the type
// of `context` (and that it contains the `Task` entity).
//
// Thanks to the first type argument in `GetTasks`, the compiler knows `args`
// is of type `Payload`.
//
// Thanks to the second type argument in `GetTasks`, the compiler knows the
// function must return a value of type `Task[]`.
}
Uninstall command
If you want to uninstall Wasp from your system, you can now do so with:
wasp uninstall
It will remove all of the Wasp binaries and data from your system.
v0.8.1
Drop the npm version requirement (#1002)
v0.8.1-rc1
Adds `wasp deploy` CLI command for Fly.io (#961)
v0.8.0
BREAKING CHANGES
- Social auth had several breaking changes as we added a new provider (GitHub).
- Buttons and sign in URLs now have a different, standardized import name for each provider.
- Google exe:
import { SignInButton as GoogleSignInButton, signInUrl, logoUrl } from '@wasp/auth/helpers/Google'
- Google exe:
- Buttons themselves have been restyled to make them more uniform, and no longer take an optional
height
parameter. - Social config object now use a
clientID
property instead ofclientId
.
- Buttons and sign in URLs now have a different, standardized import name for each provider.
GitHub added as a social login
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.
v0.7.3
MINOR CLI BREAKING CHANGE
- The CLI command for applying a migration with a name has changed from
wasp db migrate-dev foo
towasp db migrate-dev --name foo
. This allowed us to add more flags, like--create-only
.
Bug fixes
- 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.
v0.7.2
v0.7.1
v0.7.1
Bug fixes
- Fixed a bug that was causing Wasp to forget about compiling backend code before running it in production
v0.7.0
Changelog
v0.7.0 - Beta Release!
BREAKING CHANGES
- 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.
- Removes default
index.css
file that provided basicbody
defaults. Now, there is no default CSS applied. - 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
Significant changes to Wasp project structure
This was the file tree of a newly generated project in the previous version of Wasp (i.e., this was what you used to get by running wasp new project
):
.
├── ext
│ ├── Main.css
│ ├── MainPage.js
│ ├── .waspignore
│ └── waspLogo.png
├── .gitignore
├── main.wasp
└── .wasproot
This is the file tree of a newly generated project in the newest release of Wasp (i.e., this is what you will get by running wasp new project
from this point onwards):
.
├── .gitignore
├── main.wasp
├── src
│ ├── client
│ │ ├── Main.css
│ │ ├── MainPage.jsx
│ │ ├── react-app-env.d.ts
│ │ ├── tsconfig.json
│ │ └── waspLogo.png
│ ├── server
│ │ └── tsconfig.json
│ ├── shared
│ │ └── tsconfig.json
│ └── .waspignore
└── .wasproot
Main differences:
- All server-side code must be located inside the
src/server
directory. Wasp declarations must import this code withimport foo from "@server/foo"
(instead ofimport foo from "@ext/foo.js"
) - All client-side code must be located inside the
src/client
directory. Wasp declarations must import this code withimport foo from "@client/bar"
(instead ofimport bar from "@ext/bar.js"
) - All shared code (i.e., used on both the client and the server) must be located inside the
src/shared
and imported where needed through a relative import. - Each of these subdirectories (i.e.,
src/server
,src/client
, andsrc/shared
) comes with a pregeneratedtsconfig.json
file. This file helps with IDE support (e.g., jumping to definitions, previewing types, etc.) and you shouldn't delete it. The same goes forreact-app-env.d.ts
The new structure is fully reflected in our docs, but we'll also provide a quick guide for migrating existing projects.
Migrating an existing Wasp project to the new structure
You can easily migrate your old Wasp project to the new structure by following a series of steps. Assuming you have a project called foo
inside the directory foo
, you should:
-
Install the latest version of Wasp
-
Rename your project's root directory to something like
foo_old
-
Create a new project by running
wasp new foo
-
Copy all server-side code from
foo_old/ext
tofoo/src/server
-
Copy all client-side code from
foo_old/ext
tofoo/src/client
-
Copy all shared code (if any) from
foo_old/ext
tofoo/src/shared
and
adapt imports in files that reference it:- For example,
import bar from './bar.js'
becomesimport bar from "../shared/bar.js"
- For example,
-
Copy all lines you might have added to
foo_old/.gitignore
into
foo/.gitignore
-
Finally, copy
foo_old/main.wasp
tofoo/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:
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:
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", }
Do this for all external imports in your
.wasp
file. After you're done, there shouldn't be any occurences of the string"@ext"
. - Queries, Actions, Jobs, and the Server setup function must import their code from
That's it! You should now have a fully working Wasp project in the foo
directory.
[NEW FEATURE] TypeScript support
Wasp now allows you to write TS and TSX files. Some (but not all) Wasp features come with type definitions. Except more type definitions and even better integration with TypeScript in future versions!
[NEW FEATURE] Dockerfile customization
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.
[NEW FEATURE] Tailwind CSS support
You can now use the Tailwind CSS framework in your project by simply adding two config files. Check out the Integrations section of our Docs for more!
v0.7.0-rc2
TypeScript fixes before Beta (#831) * Change typescript modules to esnext * Fix tsconfigs and use recommended settings * Fix server not loading env variables * Fix TS output overwriting error * Fix wrong types * Change MainPage.tsx to MainPage.jsx * Remove duplication for Node tsconfig * Update e2e tests for TS fixes * Fix formatting
v0.7.0-rc1
Update e2e tests after supporting TypeScript (#828)