1

I'm having trouble getting my docker container to both sync volumes and autostart the dev environment.

To get volume syncing, allowing changes to code outside container to be reflected inside (while running) and vice versa; I've used the following within my docker-compose.yml:

volumes:
 - ./frontend:/frontend

Which only works if my Dockerfile does't contain:

CMD ["npm", "run", "dev"]

If the CMD line exists, I get the following error:

sh: vite: not found

Without the CMD I can exec into the container and run the command manually, but I'm aiming to have it autostart. The autostart CMD works sucessfully if the docker-compose.yml file doesn't contain the volume mapping.

I admit I'm completely new to both JS (and react) and docker, so I may have missed some key information. More than happy to provide anything requested. There are also several other threads within SO that seem similar, but alas every problem seems unique; I'm unable to ascertain where my problem is coming from; essentially why it can't find the vite command.

Thanks,

Wannabe Developer

Jamjar91
  • 25
  • 6
  • Why do you need Docker here; can you just install Node directly and use that? Since one of Docker's main goals is to isolate containers from the host filesystem it can be difficult to use it to simulate a local development environment. (I see a fair number of SO questions around live reloading not working, mostly due to needing to set up some sort of file sync between the host and container.) – David Maze May 26 '23 at 10:01
  • Thanks @David, I plan to build a webapp for something, that'll be hosted on a cloud VPS. I've got a local server to act as staging, and my local machine for development. Using docker, I can develop and push code to any of these environments and it should behave identically. But to ensure that the code will work as required first, should I have it running in a contained development environment, where the same environment can be duplicated elsewhere? Or am I completely off point? I appreciate your feedback, as mentioned, I've only just dipped my toe into these technologies. – Jamjar91 May 26 '23 at 11:50
  • A workflow I use successfully is to use local tools without Docker for day-to-day development, including unit testing, and then build an immutable image for integration testing and eventual deployment. – David Maze May 26 '23 at 13:58
  • Can I ask how you maintain a clean local dev environment then? How would you deal with different versions of packages/libraries? I would have imagined this is one of the reasons using containers for local development would be beneficial. (Not arguing your point, trying to understand a different perspective.) Thanks. – Jamjar91 May 26 '23 at 14:16
  • In a Node context, each project has its own `node_modules` directory, so it's already isolated from other applications. In practice for the most part I haven't run into a lot of trouble with things like compiler or language-runtime versions either; even browser-based applications haven't had a lot of trouble with using different major versions of Node. If it does matter, there are version managers like `nvm`. – David Maze May 26 '23 at 18:22

0 Answers0