Feat/37 client docker file #115
Conversation
pbastia
force-pushed
the
feat/37-client-docker-file
branch
5 times, most recently
from
f3f930e to
7b11d60
Compare
pbastia
force-pushed
the
feat/37-client-docker-file
branch
from
7b11d60 to
cdeb46e
Compare
client/Dockerfile
Outdated
|
|
||
| RUN yarn install --frozen-lockfile --production=false && \ | ||
| yarn build && \ | ||
| yarn install --frozen-lockfile --production=true && \ |
There was a problem hiding this comment.
What is the reasoning behind running yarn install with production set to false, and then to true?
There was a problem hiding this comment.
I was kind of wondering the same, it's setup the same way in the registration app.
I'm assuming it's to ensure the development build works as well? Maybe @dleard or @andrea-williams has context to give us
There was a problem hiding this comment.
Unless their docs are off, the only difference is that with production=false our dev dependencies will be installed. In that case the second install won't do anything. If we need something from our dev dependencies for the build to happen well, we could consider removing the node_modules after the yarn build and then running the install in production mode.
Definitely not a huge deal, I was just curious.
There was a problem hiding this comment.
I'd say - let's remove the whole dev statement. There is no need to ship a production image with dev dependencies, this might increase the attack surface if those deps have vulnerabilities?
There was a problem hiding this comment.
I agree, and if nothing else we'll shrink our image a little bit, which feels like a win win to me!
There was a problem hiding this comment.
I'm afraid I have no insight into why the Dockerfile is written that way. It's a question for either Dylan or @Sepehr-Sobhani
There was a problem hiding this comment.
This seems to be a leftover from copying and pasting the Dockerfile from CIF.
No description provided.