Questions
1. For Wasp v0.15, what's the recommended way to deploy to production with Docker? Should we bundle the server code or run it
directly from source?
2. In the Dockerfile, should we COPY . /app (entire project) or just COPY .wasp/build and .wasp/out/sdk? What's the minimal set of
files needed?
3. When should npm run bundle happen - during wasp build, during Docker build, or at server startup?
Export/Module Questions:
4. Why does wasp build complete successfully locally, but then npm run bundle fails in Docker with "not exported by youtubeApi.ts"?
Is this a Rollup configuration issue?
5. Are there specific files or directories that shouldn't be copied to Docker that might affect Rollup's ability to resolve imports?
6. For custom server code in src/server/, how does Wasp handle bundling that code along with generated code?
Architecture Questions:
7. What's the purpose of .wasp/out/sdk/ vs .wasp/build/? Which one needs to be in the Docker container for runtime?
8. Does the generated code in .wasp/build/server/src/ expect to import from the original source directory at src/server/? If so, how
should Docker be set up?
9. For environment validation (validate-env.mjs), what does it actually need to access - just the SDK, or source files too?
Debugging Questions:
10. Is there a way to test/verify the bundle locally before deploying to Docker?
11. Are there known issues with Wasp v0.15 + Rollup bundling for projects with custom workers/jobs?
5 Replies
Hi @ArDev. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
I'll answer your questions about Wasp deployment and Docker configuration based on the available documentation.
Deployment & Docker Questions
1. Recommended deployment approach:
According to the deployment documentation, you should run
wasp build to generate deployable code in .wasp/build/, then deploy the Docker image defined in that directory. The server code should be bundled during the Docker build process.
2. Minimal files needed in Docker:
Based on the GitHub issue discussion, the Docker build requires:
- .wasp/build/ directory (generated code)
- .wasp/out/sdk/ directory (SDK code)
- src/ directory (your source code)
- package.json and package-lock.json files
The build process copies these files into .wasp/build to maintain the correct directory structure. You should not copy the entire project root.
3. When npm run bundle happens:
The bundling occurs during the Docker build process, not during wasp build or at server startup. This is evident from the Discord discussion where the Dockerfile includes RUN cd .wasp/build/server && npm run bundle.
Export/Module Questions
4. Bundle failures in Docker:
The knowledge sources don't contain specific information about "not exported by youtubeApi.ts" errors. However, this could be related to how the Docker build context is set up or missing dependencies.
5. Files affecting Rollup resolution:
The knowledge sources don't provide specific information about files that shouldn't be copied that might affect Rollup's import resolution.
6. Custom server code bundling:
The GitHub issue explains that generated code in .wasp/build/server imports user code from src using relative paths. The directory structure inside the Docker image must match the outside structure for this to work.
Architecture Questions
7. Purpose of .wasp/out/sdk/ vs .wasp/build/:
According to the GitHub issue:
- .wasp/out/sdk/ contains the SDK code used by both wasp start and wasp build
- .wasp/build/ contains the generated framework code for production builds
- Both are needed in the Docker container because package.json references the SDK at .wasp/out/sdk/wasp
8. Import expectations:
Yes, the generated code in .wasp/build/server/src/ imports from the original src/ directory using relative paths. The GitHub discussion confirms that Docker must mirror the project's structure to maintain these relative imports.
9. Environment validation requirements:
The knowledge sources don't provide specific details about what validate-env.mjs needs to access.
Debugging Questions
10. Testing the bundle locally:
You can test the Docker build locally by running wasp build, then cd .wasp/build and docker build . -t test-name as shown in the Discord discussion.
11. Known issues with v0.15 + Rollup:
The knowledge sources don't contain information about specific known issues with Wasp v0.15 and Rollup bundling for projects with custom workers/jobs.
---
Note: Some of your specific questions don't have answers in the provided knowledge sources. For more detailed help with your bundling errors, I recommend joining the Wasp Discord where the team can help debug your specific issue.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @ArDev, 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 About Bundling:
1. "Why does wasp build complete successfully locally, but npm run bundle inside Docker fails to resolve exports from our custom
youtubeApi.ts file? Is this a path resolution issue during bundling?"
2. "Should we be bundling inside the Docker container at all, or should the bundled code be pre-generated before shipping to
Docker?"
3. "In v0.15, does the Rollup config automatically know where to find custom server code (src/server/), or does it need explicit
configuration?"
About Docker Setup:
4. "For Wasp v0.15 Docker deployment, what's the minimal set of files/directories that must be copied? Should it be just
.wasp/build/ + .wasp/out/sdk/, or does the entire src/ directory need to be included?"
5. "When Docker builds the image, should the project directory structure inside the container match the structure outside (i.e.,
/app/src/, /app/.wasp/build/)?"
About Generated Code:
6. "The generated code in .wasp/build/server/src/jobs/emailChecker.ts imports from
../../../../../src/server/workers/checkAndQueueEmails.js - is this import path relative to the Docker container's /app/ root, or
relative to the server directory?"
7. "Does Wasp v0.15 expect the bundler to have access to the original source files, or should bundling only work with generated
code?"
About the Deployment Pattern:
8. "What's the officially recommended Wasp v0.15 + Fly.io deployment pattern? Should we follow a specific GitHub example or
template?"
9. "Is there a reference Dockerfile that works with Wasp v0.15 that we can check against?"
Your Specific Error:
10. "The bundler reports "fetchYoutubeComments" is not exported by youtubeApi.ts - but this function IS defined in the source file.
Is this a TypeScript compilation issue before bundling, or a Rollup module resolution problem?"
Let me check the knowledge base for you again. One moment! :books:
----------------------
I'll address your questions about bundling, Docker setup, and deployment in Wasp v0.15.
About Bundling
1. Why bundling fails in Docker:
The knowledge sources don't contain specific information about export resolution failures for custom files like
youtubeApi.ts. However, based on the error message improvement discussion, import path issues in generated code can occur when files don't exist or exports are missing. The error suggests the bundler can't find your exports during the Docker build phase.
2. When bundling should occur:
According to the Docker deployment discussion, bundling happens inside the Docker container during the build process. The Dockerfile includes RUN cd .wasp/build/server && npm run bundle as part of the Docker build steps, not before.
3. Rollup configuration for custom server code:
The knowledge sources don't provide specific details about Rollup's automatic configuration for finding custom server code in v0.15.
About Docker Setup
4. Minimal files needed:
Based on the GitHub issue about wasp build, the Docker build requires:
- .wasp/build/ (generated code)
- .wasp/out/sdk/ (SDK code)
- src/ directory (your source code)
- package.json and package-lock.json
The discussion explains that these files are copied into .wasp/build to maintain proper structure.
5. Directory structure matching:
Yes, absolutely. The GitHub issue explicitly states: "We must mirror the project's structure inside the Docker image. The framework code in .wasp/build/server imports the user code from src using relative imports. The directory structure inside the image must match the outside structure for this to work."
About Generated Code
6. Import path resolution:
The GitHub discussion confirms that "generated code in .wasp/build/server imports the user's code directly using relative paths." The path ../../../../../src/server/workers/checkAndQueueEmails.js is relative to the generated file's location and expects to find your source code at that relative path within the container.
7. Bundler access to source files:
Yes, the bundler needs access to original source files. The GitHub issue explains that the generated code imports user code directly, so the bundler must be able to resolve these imports during the bundling process.
About Deployment Pattern
8. & 9. Official deployment pattern and reference Dockerfile:
The deployment documentation states that running wasp build generates a Dockerfile in .wasp/build/ that you should use. For custom modifications, the Discord discussion shows you can copy this Dockerfile to your project root and customize it.
Your Specific Error
10. Export resolution error:
The knowledge sources don't contain specific information about this exact error. However, the error message discussion mentions similar issues where missing .js extensions in imports can cause module resolution failures.
Key troubleshooting steps:
1. Ensure your youtubeApi.ts file is in the src/ directory that gets copied to .wasp/build/
2. Verify the import path in the generated code matches where the file actually exists
3. Check that the export syntax is correct (e.g., export function fetchYoutubeComments() or export { fetchYoutubeComments })
4. Test the Docker build locally: cd .wasp/build && docker build . -t test-build as shown in the Discord example
For more specific help with your bundling error, I recommend sharing your issue on the Wasp Discord where the team can help debug the exact export resolution problem.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @ArDev, 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 how can i speed up server boot time?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Based on the knowledge sources, here are some ways to potentially speed up your Wasp server boot time:
Memory and Resource Optimization
According to the GitHub issue about memory usage, Wasp switched from Create React App to Vite, which significantly reduced memory consumption from ~1GB to 200-300MB for the frontend. However, the discussion notes that "the server takes almost nothing" in terms of memory.
If you're running on limited resources, the Discord discussion mentions that 1GB might not be enough in general, as "Wasp runs quite a few things at the same time."
Development vs Production
Make sure you're using the correct command for your environment:
- Development:
wasp start - This is slower as it runs multiple processes and includes hot reloading
- Production: wasp build followed by running the built server - This should be faster as it's optimized for production
The Discord discussion explicitly warns: "How come you're running wasp start in your container? That should be for development only, deployed apps (which I'm assuming this is) should use wasp build."
Server Setup Function
If you're using a setupFn in your server configuration, this function runs on server start and is awaited before the server accepts requests. According to the server config documentation, any slow operations in your setup function will delay server boot time.
Review your setup function to ensure it's not performing unnecessary slow operations during startup.
Docker Optimization
If you're deploying with Docker, the GitHub discussions mention that Docker can have performance issues, especially on macOS due to filesystem operations. On Linux, Docker performance should be fine.
---
The knowledge sources don't contain specific configuration options or flags to speed up server boot time. For more detailed optimization advice specific to your setup, I recommend asking on the Wasp Discord.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @ArDev, 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?