if lib/package cannot be found on host fs,
we should probably throw an error.

we search for the packages before starting the container so, should not be hard to do.

--allow-missing

might be a good flag to use if we want to allow packages to not be findable, etc.

perhaps the image can be pushed and tested on ci/cd platforms?

might not be worth it, tho. just rebuild the image given the Dockerfile on remote platforms.

searchRoots (plural) is supported by r2g but not r2g.docker, need to support a list of roots not just one.

When using docker r2g, --full is the default, but it should not be the default.

allow user to change npm version along with node version

right now, we are running

npm install /home/node/cache/x
npm install /home/node/cache/y
...
npm install /home/node/cache/y

instead, we should simply copy the path to x, y, z to the package.json file, and then run npm install

docker image pull node:9.2

http://qr.ae/TUpklV

There's a few ways if you want to explore the container’s fs.

Start an interactive shell and cd/ls around: docker exec -it container bash
This requires a few things of the container though.

That there's some kind of shell and that you know the name of the shell.
That there's a ‘cd’ that or ‘ls’ command to explore with.
That the shell you enter as has access to read the directories and files.
A better way, is to docker commit the container. There will be a split second while the container is paused, but it will resume immediately after the commit.

Once it's committed, you can docker export it to a tarball and explore the file system from the host environment or another machine.