It is a common issue, not only with Docker, but also with some cloud deployments. For example deployment to CloudFoundry using standard Node.js buildpack will cause npm install/yarn to run anyway. So, you'll also need to apply some tricks to work with local modules
If you don't mind to switch from NPM to Yarn for dependency management, you can use workspaces feature.
My package.json looks like this:
{
...
"dependencies": {
"some-module-i-want-to-install": "1.0.0",
"another-module-i-want-to-install": "1.0.0",
"@my/local-dependency-one": "1.0.0",
"@my/local-dependency-two": "1.0.0"
},
"workspaces": ["packages/*"]
}
And my project source layout has the following structure:
.
├── index.js
├── package.json
├── packages
│ ├── local-dependency-one
│ │ ├── index.js
│ │ └── package.json
│ └── local-dependency-two
│ ├── index.js
│ └── package.json
└── yarn.lock
After running yarn, modules I want to install are fetched from NPM registry, and local dependencies are installed from packages directory to node_modules.
.
├── index.js
├── node_modules
│ ├── @my
│ │ ├── local-dependency-one
│ │ │ └── ...
│ │ └── local-dependency-two
│ │ └── ...
│ ├── another-module-i-want-to-install
│ │ └── ...
│ └── some-module-i-want-to-install
│ └── ...
├── package.json
├── packages
│ ├── local-dependency-one
│ │ └── ...
│ └── local-dependency-two
│ └── ...
└── yarn.lock
As you can see, I prefer to define my local packages as scoped (@my/...). It is not mandatory, but a best practice. NPM treats scoped packages as private by default, so I don't need to worry that they will be occasionally published or explicitly mark them as private.