Harish
Harish
WWasp-lang
Created by Harish on 8/23/2024 in #🙋questions
Issue with @default([]) in schema.prisma during migration from Wasp 13 to 14
I am currently migrating our production application from version 13 to 14, following the migration guide. I’ve made all the necessary code changes, but when I ran the final command, wasp db migrate-dev, I encountered the following error: Wasp couldn't parse your schema.prisma file, please check if you have any errors in it. This was a puzzle to me because the same schema used to work when it was part of the main.wasp file. After some debugging, I ran the following prisma command to check if I would encounter the same error: prisma validate --schema=./schema.prisma To my surprise, the prisma command passed and returned: The schema at schema.prisma is valid 🚀 I then created a minimal reproducible example to isolate the problem and was able to replicate the issue. Here’s the schema.prisma file that triggers the error:
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}

generator client {
provider = "prisma-client-js"
}

// Use Prisma Schema file to define your entities: https://www.prisma.io/docs/concepts/components/prisma-schema
// Run `wasp db migrate-dev` in the CLI to create the database tables
// Then run `wasp db studio` to open Prisma Studio and view your db models
model User {
id Int @id @default(autoincrement())
tasks Task[]
}

model Task {
id Int @id @default(autoincrement())
description String
isDone Boolean @default(false)
user User @relation(fields: [userId], references: [id])
userId Int
someField String[] @default([])
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}

generator client {
provider = "prisma-client-js"
}

// Use Prisma Schema file to define your entities: https://www.prisma.io/docs/concepts/components/prisma-schema
// Run `wasp db migrate-dev` in the CLI to create the database tables
// Then run `wasp db studio` to open Prisma Studio and view your db models
model User {
id Int @id @default(autoincrement())
tasks Task[]
}

model Task {
id Int @id @default(autoincrement())
description String
isDone Boolean @default(false)
user User @relation(fields: [userId], references: [id])
userId Int
someField String[] @default([])
}
The issue seems to be with the someField String[] @default([]) line. Setting the default value to @default([]) is causing the command to fail, even though this syntax worked in earlier versions of Wasp. If I remove @default([]) from the schema and rerun wasp db migrate-dev, the migration proceeds without errors. Can anyone offer some guidance or suggestions on how to address it?
9 replies
WWasp-lang
Created by Harish on 7/2/2024 in #🙋questions
Dependabot Vulnerability Alerts for Internal Dependencies
I have created a project using Wasp, based on a simplified version of the OpenSaaS template. I am receiving several Dependabot Vulnerability alerts in the GitHub repository related to the following internal dependencies of Wasp: - ws - express - follow-redirects - axios - undici I am currently using Wasp version 0.13.2. Is there a way to update these packages? Alternatively, is there a newer version of Wasp available that addresses these vulnerabilities? Link to my GH repo: https://github.com/airtai/fastagency-wasp-app-template/security/dependabot Thank you for your assistance.
19 replies
WWasp-lang
Created by Harish on 6/21/2024 in #🙋questions
Setting Fly.io machine configuration using wasp CLI deploy commands
Hi Team, Is it possible to change the default configuration of Fly.io machines using the wasp deploy fly CLI commands? I would like to run my application on a larger machine or a non-shared CPU machine. Below is the configuration of the server instance created by the Wasp deploy Fly CLI commands:
primary_region = "mia"

[http_service]
auto_start_machines = true
auto_stop_machines = true
force_https = true
internal_port = 8_080
min_machines_running = 1
processes = [ "app" ]

[[vm]]
cpu_kind = "shared"
cpus = 1
memory = "1gb"
primary_region = "mia"

[http_service]
auto_start_machines = true
auto_stop_machines = true
force_https = true
internal_port = 8_080
min_machines_running = 1
processes = [ "app" ]

[[vm]]
cpu_kind = "shared"
cpus = 1
memory = "1gb"
6 replies
WWasp-lang
Created by Harish on 4/5/2024 in #🙋questions
How to Pass Additional Parameters in SSO Login
No description
23 replies
WWasp-lang
Created by Harish on 2/20/2024 in #🙋questions
Setting Environment-specific Values in main.wasp File
Currently, in WASP, we're able to insert static og:tags in the main.wasp file's head section like: https://github.com/wasp-lang/open-saas/blob/main/app/main.wasp#L8 However, I'm exploring the possibility of dynamically assigning values to attributes such as og:image and og:url based on the environment. For instance, in the staging environment, I want to set og:imageas "https://www.staging.com/public-banner.png", whereas in production, I'd like it to be "https://www.production.com/public-banner.png". Is there a way to accomplish this dynamic behavior directly within the main.wasp file?
6 replies
WWasp-lang
Created by Harish on 2/14/2024 in #🙋questions
Preserving Query Parameters in Google Social Auth Redirects
I'm currently integrating Google Social Auth into our application. In certain instances, our login URLs contain query parameters. After users successfully authenticate through Google, we need to ensure that any query parameters from the original URL persist in the redirect URL. For instance, if a user clicks on the following link without an active login session: https://my-application/chat?message=hello The user is redirected to Google auth. Upon successful authentication, they're redirected back to: https://my-application/chat (because of onAuthSucceededRedirectTo: "/chat" in the main.wasp) However, i would it to redirected back to: https://my-application/chat?message=hello How can we configure this behaviour in WASP?
8 replies
WWasp-lang
Created by Harish on 2/6/2024 in #🙋questions
Getting Wasp Compilation Error since Yesterday
Hi Team, We've been working on a SaaS product using Wasp, and everything was fine until last Friday. Since yesterday, our GitHub CI builds started to fail during project compilation. Can anyone help us resolve this? Below is the error message. The failure is happening while running the "wasp test client run --silent" command: [Client!] npm WARN deprecated abab@2.0.6: Use your platform's native atob() and btoa() methods instead 🐝 --- Starting compilation and setup phase. Hold tight... ------------------------ 🐝 --- Compiling wasp project... -------------------------------------------------- 🐝 --- Starting npm install... ---------------------------------------------------- ...Still installing npm dependencies! ...Installation going great - we'll get there soon! ...The installation is taking a while, but we'll get there! [Server]> server@0.0.0 postinstall [Server]> patch-package [Server] [Server]patch-package 6.5.1 [Client!] npm WARN deprecated domexception@4.0.0: Use your platform's native DOMException instead [Server!] ERROR Failed to apply patch for package oauth at path [Server!] [Server!] node_modules/oauth [Server!] [Server!] This error was caused because oauth has changed since you [Server!] made the patch file for it. This introduced conflicts with your patch, [Server!] just like a merge conflict in Git when separate incompatible changes are [Server!] made to the same piece of code. [Server!] [Server!] Maybe this means your patch file is no longer necessary, in which case [Server!] hooray! Just delete it! [Server!] [Server!] Otherwise, you need to generate a new patch file. [Server!] [Server!] To generate a new one, just repeat the steps you made to generate the first [Server!] one. [Server!] i.e. manually make the appropriate file changes, then run [Server!] patch-package oauth [Server!] Info: [Server!] Patch file: patches/oauth+0.9.15.patch [Server!] Patch was made for version: 0.9.15 [Server!] Installed version: 0.10.0
23 replies