Persistent Schema again.
I'm experiencing a persistent migration state issue where Wasp is trying to apply an old schema that doesn't match my current schema.prisma file.
The Problem:
- My schema.prisma has a simple BudgetItem model
- But wasp db migrate-dev keeps trying to create phantom tables (Budget, BudgetCategory, Guest, Vendor) that don't exist in my schema
- This causes the Prisma client to not generate properly, so my budget operations aren't available
- Getting TypeScript errors like: Module '"wasp/client/operations"' has no exported member 'getBudget'
What I've tried:
1. Dropped the entire database and recreated it
2. Deleted all migration files in /migrations
3. Removed .wasp directory
4. Cleared Prisma client cache in node_modules/.prisma
5. Reset the _prisma_migrations table
Current state:
- Database is fresh (empty)
- No migration files exist
- But Wasp still tries to apply the wrong schema during wasp db migrate-dev
How can I completely reset Wasp's migration state so it uses my current schema.prisma instead of some cached version? Is there another location where Wasp stores migration state that I need to clear?
6 Replies
Hi @God. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the information in the knowledge sources, here’s how you can fully reset Wasp’s migration state and ensure it uses your current schema.prisma:
1. Delete All Migrations and Clean the Project
You’ve already deleted the
Example steps: Migrating from SQLite to PostgreSQL 2. Recreate the Database and Run Migration
- Make sure your database is running and empty. - In a new terminal, run: This will generate a new initial migration based on your current schema.prisma and apply it to the database. 3. Check for External package.json or Prisma Versions
There is a known issue where if you have a
Prisma version conflict issue 4. No Other Hidden State
According to the knowledge sources, Wasp does not store migration state in any other hidden location besides the
If after these steps Wasp still tries to apply phantom tables, double-check that: - Your
You’ve already deleted the
/migrations directory and the .wasp directory, which is good. However, Wasp also recommends running wasp clean after deleting migrations to ensure all generated files and caches are cleared. This step is crucial, as it removes any lingering state that Wasp or Prisma might be using.Example steps: Migrating from SQLite to PostgreSQL 2. Recreate the Database and Run Migration
- Make sure your database is running and empty. - In a new terminal, run: This will generate a new initial migration based on your current schema.prisma and apply it to the database. 3. Check for External package.json or Prisma Versions
There is a known issue where if you have a
package.json in a parent directory (outside your Wasp project) that includes a different version of Prisma, it can interfere with the migration and client generation process. Make sure there are no conflicting Prisma dependencies in parent directories, as npm might resolve to those instead of your local project’s dependencies.Prisma version conflict issue 4. No Other Hidden State
According to the knowledge sources, Wasp does not store migration state in any other hidden location besides the
/migrations directory, the generated .wasp directory, and the database itself. Running wasp clean after deleting migrations and resetting the database should fully clear the state.
5. If Problems PersistIf after these steps Wasp still tries to apply phantom tables, double-check that: - Your
schema.prisma in the generated code (usually under .wasp/out/db/) matches your intended model.
- There are no old migration files or schema files lingering in the generated output.
- You are running commands from the correct project directory.
Summary of Steps:
1. Delete /migrations and .wasp directories.
2. Run wasp clean.
3. Ensure the database is empty.
4. Run wasp db migrate-dev to generate and apply a fresh migration.
If you follow these steps, Wasp should use your current schema.prisma and not any cached or phantom schema. If the issue persists, it may be due to an external Prisma version conflict or a bug, in which case checking for external package.json files or reporting the issue may be necessary.
Let me know if you need more specific troubleshooting!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @God, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?@kapa.ai
I'm experiencing multiple issues preventing my Wasp project from compiling:
Issue 1: npm install failing with 'Invalid Version' error
- Error occurs when running any wasp command
- npm error log shows: TypeError: Invalid Version: related to fsevents
- Tried clearing node_modules, package-lock.json, and npm cache
Issue 2: Migration state mismatch
- My schema.prisma has BudgetItem model with simple structure
- But migrations try to create phantom tables (Budget, BudgetCategory, Guest, Vendor)
- This prevents Prisma client from generating budget operations
What I've tried:
1. Removed node_modules and package-lock.json
2. Cleared npm cache
3. Dropped entire database
4. Deleted all migration files
5. Removed .wasp directory
6. Reset _prisma_migrations table
Environment:
- Node v20.19.1
- npm v10.8.2
- Wasp v0.16.3
- WSL2 on Windows
The npm install either fails with 'Invalid Version' or hangs indefinitely. This is blocking all Wasp commands. How can I resolve these issues to get my project working again?
Let me check the knowledge base for you again. One moment! :books:
Wohooo @God, you just became a Waspeteer level 1!
----------------------
You’re encountering two main issues: an npm install failure with an “Invalid Version” error (related to fsevents), and a persistent migration state mismatch in your Wasp project. Here’s what the knowledge sources suggest:
---
1. npm install failing with 'Invalid Version' (fsevents)
- fsevents is an optional dependency for macOS, and errors related to it are often warnings on non-macOS systems. However, a true “Invalid Version” error may indicate a corrupted dependency or a version mismatch.
- Common Fixes:
- Run
See: Discord thread on fixing broken .wasp and node_modules - If
See: Prisma version conflict issue - Network issues or low system resources (like RAM) can also cause npm install to hang or fail. One user found that running on a VPS with only 512MB RAM caused persistent npm install failures.
See: Discord thread on npm install failing due to low RAM --- 2. Migration State Mismatch - If you’ve deleted all migration files, dropped the database, removed
See: Prisma version conflict issue - If you run Prisma commands before running
See: Discussion on running Prisma commands before npm install --- 3. Node and npm Version Compatibility - Wasp recently added support for Node 20, but if you’re using a version of Wasp or dependencies that are not fully compatible, you may encounter issues. If possible, try using Node 18 to see if the problem persists, as Node 18 is the most widely tested version for Wasp.
See: Node version support discussion --- Recommended Steps 1. Ensure Sufficient System Resources:
If running in a VM or VPS, make sure you have at least 1GB of RAM. 2. Check for Conflicting package.json Files:
Make sure there are no parent directories with a
If
See: Debugging npm install in generated folders 4. Try Node 18:
If the above fails, try switching to Node 18 using nvm, as this is the most stable version for Wasp at the moment. --- If after all these steps the problem persists, and especially if the “Invalid Version” error continues, it may be a deeper compatibility or environment issue not covered in the current knowledge sources. In that case, please provide the full npm error log and consider opening an issue on the Wasp GitHub or asking in the Wasp Discord for more targeted help. Let me know if you need more specific troubleshooting based on the error logs! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @God, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
wasp clean to remove all build artifacts and node_modules, then try wasp start again. This is a recommended step for resolving broken states in Wasp projects, especially when npm or node_modules issues are involved.See: Discord thread on fixing broken .wasp and node_modules - If
wasp clean and a fresh install still fail, check your project’s and parent directories for any conflicting package.json files or dependencies, especially those specifying incompatible versions of dependencies like Prisma or fsevents.See: Prisma version conflict issue - Network issues or low system resources (like RAM) can also cause npm install to hang or fail. One user found that running on a VPS with only 512MB RAM caused persistent npm install failures.
See: Discord thread on npm install failing due to low RAM --- 2. Migration State Mismatch - If you’ve deleted all migration files, dropped the database, removed
.wasp, and run wasp clean, Wasp should not be applying old migrations or phantom tables. There is no other hidden migration state according to the knowledge sources.
- Possible Causes:
- There may be a mismatch between the schema in your source and the generated code. Double-check that .wasp/out/db/schema.prisma matches your intended model.
- If you have a package.json in a parent directory with a different Prisma version, npm might resolve to that, causing unexpected behavior.See: Prisma version conflict issue - If you run Prisma commands before running
npm install (or before Wasp does it), you might get into a broken state.See: Discussion on running Prisma commands before npm install --- 3. Node and npm Version Compatibility - Wasp recently added support for Node 20, but if you’re using a version of Wasp or dependencies that are not fully compatible, you may encounter issues. If possible, try using Node 18 to see if the problem persists, as Node 18 is the most widely tested version for Wasp.
See: Node version support discussion --- Recommended Steps 1. Ensure Sufficient System Resources:
If running in a VM or VPS, make sure you have at least 1GB of RAM. 2. Check for Conflicting package.json Files:
Make sure there are no parent directories with a
package.json that could interfere with dependency resolution.
3. Full Clean and Reinstall:If
wasp start fails, try running npm install manually in .wasp/out/web-app and .wasp/out/server to see more detailed errorsSee: Debugging npm install in generated folders 4. Try Node 18:
If the above fails, try switching to Node 18 using nvm, as this is the most stable version for Wasp at the moment. --- If after all these steps the problem persists, and especially if the “Invalid Version” error continues, it may be a deeper compatibility or environment issue not covered in the current knowledge sources. In that case, please provide the full npm error log and consider opening an issue on the Wasp GitHub or asking in the Wasp Discord for more targeted help. Let me know if you need more specific troubleshooting based on the error logs! ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @God, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?
Hey @God, this is very strange...
A couple of questions to help figure it out:
- Which system are you using
- What's your version of Wasp and Node
- Can you share your project so I could check it out (we can do this over DMs)