You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nuxt Version: "nuxt": "^3.10.3",
Docker Version: 4.28.0 (139021)
Operating System: Windows 11 Version 10.0.22631 Build 22631, MacOS Ventura (latest official)
Describe the bug
We are encountering an issue with Hot Module Replacement (HMR) within a Docker environment on both MacOS and Windows (using WSL 2.0). Specifically, the problem involves adding new files to the pages and server directories of our Nuxt 3 application. Changes to existing files, including components, styles, and text contents, are correctly recognized and processed. However, new files added for routes in pages or for APIs in server are not detected until the Docker container or the Nuxt server is restarted.
Steps to Reproduce
Start the Nuxt application in a Docker container.
Add a new file to the pages directory to create a new route.
Attempt to access the new route or wait for HMR to detect the change.
Repeat steps for adding a new file in the server directory for an API.
Expected Outcome: Changes or new files should be recognized by HMR and applied immediately.
Actual Outcome: New files are only recognized and processed after restarting the Docker container or Nuxt server.
Potential Causes
It appears that the HMR configuration or Docker settings may not be correctly set up to detect new files in the filesystem. The issue could be related to the watch configuration or specific settings for Docker environments that affect filesystem change detection.
Attempted Solutions
Enabled polling in the Vite configuration (as shown in the provided code snippet).
Tried various host and HMR settings.
Unfortunately, these approaches did not resolve the issue.
This is my docker-compose.yml (lies at same-root level):
version: '3.8'services:
app-nuxt:
image: oven/bun:latest # The image namecontainer_name: app-nuxtports:
- "3000:3000"
- "24678:24678"volumes:
- .:/appworking_dir: /app # Set working directory to where your app isrestart: alwayscommand: sh -c "bun install && bun run dev"environment: # Correct command to install dependencies and run dev server
- NODE_ENV=developmentuser: bun
This is corresponding nuxt.config.ts with adjustments for local dev server (page / server changes not reflecting):
Environment
Reproduction example for the described use case (pages & api functionality):
https://stackblitz.com/edit/github-drgy5q?file=nuxt.config.ts
Reproduction
Environment
Nuxt Version: "nuxt": "^3.10.3",
Docker Version: 4.28.0 (139021)
Operating System: Windows 11 Version 10.0.22631 Build 22631, MacOS Ventura (latest official)
Describe the bug
We are encountering an issue with Hot Module Replacement (HMR) within a Docker environment on both MacOS and Windows (using WSL 2.0). Specifically, the problem involves adding new files to the pages and server directories of our Nuxt 3 application. Changes to existing files, including components, styles, and text contents, are correctly recognized and processed. However, new files added for routes in pages or for APIs in server are not detected until the Docker container or the Nuxt server is restarted.
Steps to Reproduce
Expected Outcome: Changes or new files should be recognized by HMR and applied immediately.
Actual Outcome: New files are only recognized and processed after restarting the Docker container or Nuxt server.
Potential Causes
It appears that the HMR configuration or Docker settings may not be correctly set up to detect new files in the filesystem. The issue could be related to the watch configuration or specific settings for Docker environments that affect filesystem change detection.
Attempted Solutions
Unfortunately, these approaches did not resolve the issue.
This is my docker-compose.yml (lies at same-root level):
This is corresponding nuxt.config.ts with adjustments for local dev server (page / server changes not reflecting):
Additional context
No response
Logs
No response
The text was updated successfully, but these errors were encountered: