Please feel free to create an issue or open a pull request if you need support or would like to contribute.
node
, package managers and build tools2019-02-25
node
v11 images and testsnode-11-alpine
image (you can always use the DOCKER_NPM_TAG
variable to use another image).Images are tagged according to the installed Node version and operating system. Package versions are not pinned, instead npm
is executed to install current versions of each package. If stability issues aries, I will pin package versions in a Dockerfile
for that Node/OS version and create a image tagged as stable
based on it. Please let me know if you run into this situation.
alpine
, latest
DockerfileBased on node:alpine
. This image should be considered under development and may not be as stable as versioned images.
node-11-alpine
DockerfileBased on node:11-alpine
.
node-10-alpine
DockerfileBased on node:10-alpine
.
node-9-alpine
DockerfileBased on node:9-alpine
.
node-8-alpine
DockerfileBased on node:8-alpine
.
node-7-alpine
DockerfileBased on node:7-alpine
.
node-6-alpine
DockerfileBased on node:6-alpine
.
debian
DockerfileBased on node:latest
. This image should be considered under development and may not be as stable as versioned images.
node-11-debian
DockerfileBased on node:11-stretch
.
node-10-debian
DockerfileBased on node:10-wheezy
.
node-9-debian
DockerfileBased on node:9-wheezy
.
node-8-debian
DockerfileBased on node:8-wheezy
.
node-7-debian
DockerfileBased onnode:7-wheezy
.
node-7.7-alpine
, 7.0-alpine
Dockerfile Based on node:7.7-alpine
, it node
v7.7 compiled from source. The 7.0-alpine
tagged version was accidentally upgraded over time to v7.7 and will remain so for the stability of existing users.
node-6.9-alpine
, 6.9-alpine
Dockerfile Based on alpine:3.4
with node
v6.9 compiled from source.
node-7.0-debian
, 7.0-debian
Dockerfile Based onnode:7.0-wheezy
.
node-6.9-debian
, 6.9-debian
Dockerfile Based onnode:6.9-wheezy
.
Essentially, this is just a set of shell scripts that manage a Node.js docker image. The docker image includes a script (run-as-user
) that allows commands to write files as either the current user or the owner/group of the current directory, which the shell scripts take advantage of to make sure files are created with your preferred permissions rather than root.
The images contain the latest stable bower
, generate-md
, grunt
, gulp
, node
, npm
, npx
, and yarn
, binaries for node
. When using the shell scripts available in the source repository, the current directory is mounted into /src
inside the container and a wrapper script executes the specified command as a user who's uid
and gid
matches those properties on that directory. This way any output is written as the directory owner/group instead of root or a random user.
The included run-as-user
script has three methods of determining which uid
and gid
to execute as:
By default, it will execute with a uid
and gid
that matches the current directory (the one that gets mounted into /src
).
In order to take advantage of public key authentication when installing packages from private repositories, all the wrapper scripts will attempt to mount your ~/.ssh
directory into the container. When that is successful, the script will run as the uid
and gid
of the owner of ~/.ssh
(you).
Most software that takes advantage of public key authentication protocols do so over SSH, and by default, send the current user name as the login name. Because this process is executing out of a segregated container, it knows nothing about the current user's name and will instead try to login as a user named dev
. In order to work around this, you need to create a SSH configuration that specifies the correct username.
In your ~/.ssh
folder create a file called config
. In that file you need to specify the correct username. For example, to specify your login name for all hosts:
Host *
User mkenney
You can easily be more explicit as well, specifying by host or with additional wildcards. Google is your friend.
Host github.com
User mkenney
You can also explicitly specify the uid
and gid
to use at runtime by defining the PUID
and PGID
environment variables when executing the container, this is quite useful in automated build systems:
docker run \
--rm \
-it \
-v $(pwd):/src:rw \
-e "PUID=<user id>" \
-e "PGID=<group id>" \
mkenney/npm:latest <commands>
The included wrapper scripts default to the latest node version and image tag I feel is stable, I will update the default tag as updates are released or stability issues warrant (node-10-alpine
at the moment).
To specify a different image, you can define the image tag in your environment which will set a new default (you probably want to define this in your .bashrc
or similar profile script):
export DOCKER_NPM_TAG=node-6.9-alpine
or you can easily specify it at runtime whenever necessary, for example:
$ DOCKER_NPM_TAG=node-6.9-alpine bower install
If you would to see like additional node modules and/or wrapper scripts added to this project please feel free to create an issue or open a pull request.
This assumes that you already have Docker installed. A running docker
daemon is required. You probably want to be able to run docker commands without sudo, but even if you excute the scripts with sudo files will be written with the appropriate uid
and gid
.
Wrapper scripts for several commands are available in the source repository:
Installation is just a matter of putting them somewhere in your path and making them executable. An installation script is available and can be executed with a shell curl
+sh -s
command. Simply pass in your command arguments normally.
Usage
install.sh COMMAND [TAG [PREFIX]]
Synopsys
Install a mkenney/npm container execution script locally
Options
COMMAND - Required, the name of the command to install (bower, gulp, npm, etc.)
TAG - Optional, the image tag to use. Default 'latest'
PREFIX - Optional, the location to install the command script. Default '$HOME/bin'
Examples
$ curl -L https://raw.githubusercontent.com/mkenney/docker-npm/master/bin/install.sh | bash -s gulp node-10-alpine $HOME/bin
$ bash ./install.sh gulp node-10-alpine $HOME/bin
[command] self-update
Each of the scripts have a self-update
command which pulls down the latest docker image (which all the scripts share) and then updates the shell script itself. If you don't have write permissions on the shell script you'll get a permissions error, you can run the self-update command with sudo
if necessary.