Concatenating RUN commands into 1. Adding entrypoint to start

[jrock2004]

I want to accomplish two things with this PR.

• Reduce the amount of layers that the Docker container creates
• Add an entrypoint file so that when the image is used the first time the code is checked out, that it will download the required NPM and or Bower dependencies

This fixes issue #12

[danlynn]

I like your reminder to compact down the layers again. I'll do that - but with a slightly different order and combination than what you suggested.

Regarding the entrypoint.sh script, we'll have to skip that. I often do similar things in my own usage of the container. However, I leave it outside of the image and implemented via docker run options or docker-compose.yml file. This is because the individual usages of the container may be in opposition of that. For instance, if you are using the image in an AWS Fargate context where you are dynamically scaling up/down the container count based on traffic, you would not want to be checking npm for updates or installing bower on each container start.

I'll be updating the README with much better mini tutorials on how to use the image for new projects and with existing projects upon checkout. In the existing project mini-tutorial, I'll be sure to show an example of including an entrypoint.sh script like yours.

[jrock2004]

The reason I added the entrypoint because not doing a yarn/npm install seems like a feature that everyone needs. There is only so much I can add to a docker compose file. But I guess what you are saying is that if the person wants that then they have to override

[danlynn]

Ha! Ok, that was kindof a weird example in my previous comment. But, basically, it boils down to people do so many random things upon container start, that providing a default baked into the image doesn't make sense. For example, if you are running docker-machine then you may have a side-channel ssh connection setup for forwarding the ssh-agent port into the image for auth to private git repos rather than mounting your private key into the image. As part of this, you might be running your own script to setup the ssh config within the container to enable the ssh-agent forwarding.

Also, adding an entrypoint.sh script at this point will change the default behavior that people who are using the image expect which may cause further issues. For example, someone may have their project running great and stable and then, all of a sudden, their project acts different or fails because they haven't locked down their version dependencies well enough in their package.json. The new entrypoint.sh helpfully updated their dependencies to the very latest which just happened to break something in their app. Thus, now they have to spend their time running that down rather than on the work that they were right in the middle of.

[jrock2004]

Point taken and understood.

[NullVoxPopuli]

Are people using this image in production? Imo, spa docker images should be development only, as the app is just compiled down to static assets