-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Open
Labels
Affects: ConfigurationRelated to the configuration of the dev/staging/prod environments, CI, docker, etc. [managed]Related to the configuration of the dev/staging/prod environments, CI, docker, etc. [managed]Lead: @cdriniIssues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed]Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed]Module: DockerIssues related to the configuration or use of Docker. [managed]Issues related to the configuration or use of Docker. [managed]Priority: 3Issues that we can consider at our leisure. [managed]Issues that we can consider at our leisure. [managed]Theme: DevelopmentIssues related to the developer experience and the dev environment. [managed]Issues related to the developer experience and the dev environment. [managed]Type: Refactor/Clean-upIssues related to reorganization/clean-up of data or code (e.g. for maintainability). [managed]Issues related to reorganization/clean-up of data or code (e.g. for maintainability). [managed]
Milestone
Description
Description
Because we volume mount ./ to /openlibrary, /openlibrary/node_modules (which is populated when npm install is run inside the Dockerfile) gets rewritten by what's in the local directory. We've solved this issue by adding another volume mount specifically to /openlibrary/node_modules. This has had the unintended consequence that if the images are rebuilt, even though npm install is run there, when they are launched, they attach to the volume which contains the old version of /openlibrary/node_modules. So npm install has to be run again to update the volume.
What we want:
- Rebuilding the image should run
npm install - Running
docker-compose upshould NOT require runningnpm install - Running
docker-compose upshould have the same npm versions from the image.
External links:
- https://jdlm.info/articles/2016/03/06/lessons-building-node-app-docker.html#the-node_modules-volume-trick : a guide on how this problem was handled in 2016 on another project. They use the same kind of volume mount trick, but using non-named / non-persistent volumes. I will investigate whether moving back to non-named volumes will guarantee they are created fresh every
docker-compose upwith the correct and latestnode_modulesfrom the base image.
The article has a very good description of the node_modules problem in the section "The node_modules Volume Trick" and how mounting the local dev dir overwrites the installed image modules with the empty hostnode_modules. The blue / red filenames is a great way to illustrate a problem (I have found) difficult to describe clearly.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Affects: ConfigurationRelated to the configuration of the dev/staging/prod environments, CI, docker, etc. [managed]Related to the configuration of the dev/staging/prod environments, CI, docker, etc. [managed]Lead: @cdriniIssues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed]Issues overseen by Drini (Staff: Team Lead & Solr, Library Explorer, i18n) [managed]Module: DockerIssues related to the configuration or use of Docker. [managed]Issues related to the configuration or use of Docker. [managed]Priority: 3Issues that we can consider at our leisure. [managed]Issues that we can consider at our leisure. [managed]Theme: DevelopmentIssues related to the developer experience and the dev environment. [managed]Issues related to the developer experience and the dev environment. [managed]Type: Refactor/Clean-upIssues related to reorganization/clean-up of data or code (e.g. for maintainability). [managed]Issues related to reorganization/clean-up of data or code (e.g. for maintainability). [managed]