Container not installing node modules

[Djazz1995]

Hello,

I removed the node_modules from my project on my local computer and let the container do the install, but i get the following.

Error loading the local develop command. Strapi might not be installed in your "node_modules". You may need to run "npm install". The container exits after this message.

This is my docker-compose file

services:
  postgres:
    image: postgres
    environment:
      - POSTGRES_DB=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres_password
    networks:
      - backend
    volumes:
      - ./data:/var/lib/postgresql/data
  strapi:
    image: strapi/strapi
    environment:
      - DATABASE_CLIENT=postgres
      - DATABASE_NAME=postgres
      - DATABASE_HOST=postgres
      - DATABASE_PORT=5432
      - DATABASE_USERNAME=postgres
      - DATABASE_PASSWORD=postgres_password
    volumes:
      - ./strapi:/srv/app
    depends_on:
      - postgres
    networks:
      - backend
    ports:
      - '1337:1337'
networks:
  backend:
    driver: bridge```

[alexandrebodin]

Hi, did you delete the folder or just the files inside ? if so you might have hidden files still in there and strapi won't install the packages if is not empty :)

[maggie44]

If I understood what you are doing, then:

    volumes:
      - ./strapi:/srv/app

is overwriting /srv/app in the container with ./strapi from your local system. So if you deleted node_modules from your local system (./strapi), they won't exist in the container now either. The volume command won't merge the folders (i.e. keep the docker container node_modules and the rest of the stuff from your local system), but will overwrite the entire folder.

I'm throughly confused by the workflow of the docker container. It appears that all of the package.json and related files are mounted to the local file system. I'm not sure what the thinking is behind this, as it prevents us updating with docker-compose pull as the system is designed. Instead, we are supposed to go in to the container and do a new yarn install every time there is an update? And manually update our package.json file (https://strapi.io/documentation/developer-docs/latest/guides/update-version.html#upgrade-your-dependencies)? This defeats many of the object of docker containers.

@alexandrebodin it would be good to get some clarity on if my understanding of the workflow above is correct. How I would have expected it to work (although keeping in mind there seems to be a lot of ways to run strapi so I may have missed some):

1. In the Dockerfile the yarn install command would have been executed, rather than in the entry point script. As the entry point script doesn't seem to have any way to pass env variables to it, there isn't much reason not to build before hand?
2. The built folders would then be moved into the container and redundant items are stripped out where necessary (a docker multistage build to do this in order to avoid the overhead).
3. The folder wouldn't be mounted locally to the system so that it would always be updated with each new docker pull
4. The rest of the files in /srv/app would continue to be mounted, as they are customisable (and read/write often which benefits from being in a volume or mounted dir).
5. $DATABASE_CLIENT and other variables would be passed from Docker compose and the build would access them directly, rather than baking them into the app.

I'm bound to be missing lots of angles here. And achieving some of this would obviously be difficult.

@Djazz1995 if my understanding is correct then I don't think the docker container is going to be much use for you in updating (unless you do some hacky fixes), you may be better off sticking with the local install until the Docker workflow changes.

Racking my brains for an alternative. I guess the quickest dirtiest way would just be to mount the packages folder into a volume like this: - /srv/app/node_modules. Same for the packages.json. But after each launch of the container you will get a new dangling volume to remove.

Another way would be in reverse, mount the folders that you want to keep on your system one by one:

• ./strapi/api:/srv/app/api
• ./strapi/config:/srv/app/config

etc.

*Speculating not testing, so do backup first.

I would also love to get some pointers on the best way around this.

[alexandrebodin]

Hi @maggie0002 you are mostly right :) This image is really here for dev purposes to simplify the auto creation of a new app. We don't pre build node_modules because youc an install plugins etc so we make it really up to the user.

When moving to production you should create a Dockerfile indeed to avoid thos downfalls :) that is a basic example to create a Dockerfile https://github.com/strapi/strapi-docker/tree/master/examples/custom

[alexandrebodin]

I will close the issue as it is the intended behavior. If you have some optimization suggestion please tell me we can always improve the current image :)

[maggie44]

What is the prod compose file for? https://github.com/strapi/strapi-docker/blob/master/examples/prod/docker-compose.yml

This is the one I had thought would have more specific volumes mounted. Namely just the ones that are user specific configs, rather than package.Json and node_modules.

That would be easier if there was a ‘config’ folder that contained all the user specific files created during the ‘strapi new’ build process, then that one folder could be mounted.

Although this suggest there may be some folders that are static so the prod could mount these folders? https://strapi.io/documentation/developer-docs/latest/concepts/templates.html#creating-a-template