Coder Social home page Coder Social logo

mkenney / docker-npm Goto Github PK

View Code? Open in Web Editor NEW
53.0 3.0 28.0 376 KB

npm, yarn, node, npx, bower, grunt, gulp, generate-md - build and dev tools.

License: MIT License

Shell 30.76% JavaScript 0.29% Dockerfile 68.95%
node npm bower gulp grunt yarn markdown docker devops developer-tools build-tools

docker-npm's Introduction

docker-badges.webbedlam.com

npm and related build and dev tools

MIT License stability-mature Build status Github issues Github pull requests

Please feel free to create an issue or open a pull request if you need support or would like to contribute.

Portable node, package managers and build tools

Announcements

v1.1.0 released

2019-02-25

  • Added node v11 images and tests
  • Updated the shell scripts to default to node-11-alpine image (you can always use the DOCKER_NPM_TAG variable to use another image).

Tagged Images

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

Based on node:alpine. This image should be considered under development and may not be as stable as versioned images.

Based on node:11-alpine.

Based on node:10-alpine.

Based on node:9-alpine.

Based on node:8-alpine.

Based on node:7-alpine.

Based on node:6-alpine.

Debian

Based on node:latest. This image should be considered under development and may not be as stable as versioned images.

Based on node:11-stretch.

Based on node:10-wheezy.

Based on node:9-wheezy.

Based on node:8-wheezy.

Based onnode:7-wheezy.

Other Images

stability-locked 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.

stability-locked Based on alpine:3.4 with node v6.9 compiled from source.

stability-locked Based onnode:7.0-wheezy.

stability-locked Based onnode:6.9-wheezy.

About

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.

Images & Wrapper Scripts

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.

Installation

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
Updating
  • [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.

docker-npm's People

Contributors

arnested avatar bretmette avatar dagomar avatar jklewa avatar mkenney avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

docker-npm's Issues

Local gulp not found in /src

So I'm just trying to use this to run gulp, I installed the install script and used it to grab gulp. Then I grabbed the wrapperfile but whenever I try to execute it I get

[22:34:57] Local gulp not found in /src [22:34:57] Try running: npm install gulp

Was there an install step I missed?

bower asking for allow-root option

src elvis$ bower install featherlight --save 
bower ESUDO         Cannot be run with sudo

Additional error details:
Since bower is a user command, there is no need to execute it with superuser permissions.
If you're having permission errors when using bower without sudo, please spend a few minutes learning more about how your system should work and make any necessary repairs.

http://www.joyent.com/blog/installing-node-and-npm
https://gist.github.com/isaacs/579814

You can however run a command with sudo using --allow-root option

Not sure if I accidentally modified something or if this is a known issue. Have you seen this before? For now I am just executing with --allow-root and it is not effecting the permissions on the host. What are your thoughts @mkenney ?

Feature request: add npx so we can easily use global packages without installing them

Hi,

Locally I have this Dockerfile:

FROM mkenney/npm:node-8-alpine RUN npm install --silent -g npx

I've adapted a shell script in similar fashion to the ones in this repo, but which uses my local Dockerfile build for npx. Npx is great because it allows us to run global npm scripts without installing them. For instance to create a react project this would be:

npx create-react-app my-app

This works beautifully. I have a pull request (#142) which adds this to the repository. Potentially a nice addition for this would be to allow npx to install the scripts in a specified folder under the users $HOME, so that it doesn't need to download everything every time you run the command, which would enhance the speed greatly. Very curious about your thoughts.

Npm and Yarn cache

Hello,

Thanks for this awesome project, I started working on dockerizing my dev environment and I found your repo! ๐Ÿ˜„

Would it be possible to add an option to enable caching for both npm and yarn commands ?

I think it would require to mount another volume where the cache folder is expected for both tools.

Epic - Create a smarter installer for the container wrapper scripts

The primary blocker for switching to a feature-branch strategy is the image and branch definition in the wrapper scripts.

The proposed solution is to abstract the version definition out of the wrapper scripts in some way and and develop a uniform way of installing the scripts locally.

An initial experiment and subsequent updates have proven to be worth exploring further.

The current install script is still dependent on the version branches. Refactor as necessary to abstract away that dependency.

Alpine image build time unnecessarily blocks ci workflow

The alpine image takes about 35 minutes to build in travis-ci and between 30 minutes and another hour on Docker Hub. Some changes (README.md, anything in bin/, etc.) don't require running the full test suite.

Create a script to control which travis-ci tests are executed based on which files have been updated.

yarn ".roadrunner.json" error

There is a bug in the yarn package that is currently affecting all of the debian based images: yarnpkg/yarn#1724

When that is resolved and the packages are updated I'll close this. In the meantime, the build has been updated to prevent yarn errors from halting deployments. Because of the way upstream changes trigger builds in docker hub, there's no easy way to prevent the issue from creeping into the images there.

Epic - Migrate each build from it's version-branch to a sub-folder of a single branch

Migrate all image builds from each branch to a sub-folder of a single-branch and remove the wrapper scripts.

All CI test and build scripts should be updated and abstracted to create the correct test suites for each version folder as appropriate.

CI test scripts should be updated to use the updated installer to ensure the script wrappers always work and use the correct image versions.

Problem with alpine branch

Hi!
I use your image to install and build npm packages
docker run -it --rm -v $(pwd):/data mkenney/npm npm install --prefix /data
before switch to alpine, it works fine (currently all works with debian branch).
In alpine branch case i have error:

gyp WARN EACCES user "undefined" does not have permission to access the dev dir "/root/.node-gyp/6.2.2"
gyp WARN EACCES attempting to reinstall using temporary dev dir "/data/node_modules/bufferutil/.node-gyp"
gyp ERR! build error
gyp ERR! stack Error: not found: make
gyp ERR! stack     at getNotFoundError (/usr/local/lib/node_modules/npm/node_modules/which/which.js:14:12)
gyp ERR! stack     at F (/usr/local/lib/node_modules/npm/node_modules/which/which.js:69:19)
gyp ERR! stack     at E (/usr/local/lib/node_modules/npm/node_modules/which/which.js:81:29)
gyp ERR! stack     at /usr/local/lib/node_modules/npm/node_modules/which/which.js:90:16
gyp ERR! stack     at /usr/local/lib/node_modules/npm/node_modules/which/node_modules/isexe/index.js:44:5
gyp ERR! stack     at /usr/local/lib/node_modules/npm/node_modules/which/node_modules/isexe/access.js:8:5
gyp ERR! stack     at FSReqWrap.oncomplete (fs.js:117:15)
gyp ERR! System Linux 3.13.0-83-generic
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /data/node_modules/bufferutil
gyp ERR! node -v v6.2.2
gyp ERR! node-gyp -v v3.4.0
gyp ERR! not ok
...
...
npm ERR! Linux 3.13.0-83-generic
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--prefix" "/data"
npm ERR! node v6.2.2
npm ERR! npm  v3.10.8
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script 'node-gyp rebuild'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the bufferutil package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs bufferutil
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls bufferutil
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /src/npm-debug.log

My package.json

  "dependencies": {
    "bootstrap-less": "3.3.8",
    "flux": "3.1.0",
    "react": "15.3.2",
    "react-dom": "15.3.2",
    "react-router": "2.8.1",
    "material-ui": "0.16.1",
    "less": "2.7.1",
    "font-awesome": "4.6.3",
    "react-tap-event-plugin": "1.0.0",
    "classnames": "2.2.5",
    "query-string": "4.2.3",
    "react-paginate": "2.2.3",
    "moment": "2.14.1",
    "react-intl":"2.1.5",
    "autobahn-react":"0.3.1",
    "jwt-payload-decoder":"1.2.4",
    "react-count-to": "0.5.1",
    "mime-types": "2.1.12",
    "promise-polyfill": "6.0.2"
  },
  "devDependencies": {
    "babelify": "7.3.0",
    "browser-sync": "2.17.5",
    "browserify": "13.1.0",
    "eslint": "3.8.1",
    "nodemon": "1.11.0",
    "rework": "1.0.1",
    "rework-npm": "1.0.0",
    "rework-npm-cli": "0.1.1",
    "serve": "1.4.0",
    "uglify-js": "2.7.3",
    "watchify": "3.7.0",
    "bufferutil": "1.2.1",
    "utf-8-validate": "1.2.1"
  }

browserSync has trouble when connecting to the external IP

I am seeing a bit of unexpected and unpredictable behavior when using browserSync on the external IP. Aside from the issue with the WordPress redirect I am also seeing odd behavior in that some connections are refused (especially when coming in quickly, loading a page, etc).

Other times I just get a crash with little information other than --

ERROR: dial unix /Users/bmette/Library/Containers/com.docker.docker/Data/*00000003.00000948: connect: connection refused

Pass extra docker specific parameters

Hello,

There are use cases where it would be useful to be able to pass extra parameters to the underlying docker run command.

For example to expose a specific port at runtime (when working with web servers).

This is how I did it :

#!/usr/bin/env sh

TAG=node-10-alpine
if [ "" != "$DOCKER_NPM_TAG" ]; then
    TAG="$DOCKER_NPM_TAG"
fi
SCRIPT=yarn
INSTALL_SCRIPT=https://raw.githubusercontent.com/mkenney/docker-npm/master/bin/install.sh

if [ "self-update" = "$1" ]; then
    docker pull mkenney/npm:$TAG
    curl -f -L -s $INSTALL_SCRIPT | sh -s $SCRIPT $TAG $(dirname $0)
else
    if [ -t 0 ]; then
        term_type=ti
    else
        term_type=i
    fi

+    DOCKER_ARGS=""
+    YARN_ARGS=${@#* -- }
+
+    case "$@" in
+        *" -- "*) DOCKER_ARGS=${@% -- *};;
+    esac

    docker run \
        --rm \
        -$term_type \
        -v $HOME/.cache/yarn:/home/dev/.cache/yarn:rw \
        -v $(pwd):/src:rw \
        -v $HOME/.ssh:/home/dev/.ssh:ro \
+        $DOCKER_ARGS \
+        mkenney/npm:$TAG /usr/local/bin/$SCRIPT $YARN_ARGS
fi

Usage : yarn -p 3000:3000 -- start

Invalid github SSL certificate results in empty executable scripts on `self-update`

See #5 for context.

When calling self-update, wget is used to update the executable scripts. In the case where an SSL certificate can't be verified, wget ends up writing out an empty file, destroying the script.

Instead, write out a temporary file and on success overwrite the executable. Also, add a clear error message if the script update fails.

Remove run-as-user command because it is also the entrypoint

I found that when using the provided shell scripts the docker container fails to run the desired command. Instead the command that is send to the container is:

/run-as-user /run-as-user /usr/local/bin/{script} [...]

I was able to see with 'top' that the above was the command which was running without ever finishing. Removing the /run-as-user from the shell scripts worked for me. I have created a pull request with the changes:

#140

Build tools in `alpine` images

I have been leaving the build tools (gcc, g++, make, etc.) out of the alpine images to reduce the overall image size, however I find that most of the issues I have that trace back to the image itself have to do with missing build tools and on many projects I end up using the debian based image anyway.

As it has also caused problems for others (#9, #17, #18) I may add those tools back in to the image in the near future and I'm not sure how much it will add to the image (50 - 100MB or so I would guess). Please let me know if anyone has any concerns with that.

@arnested @NewOldMax @VeeeneX

Node 12

Node v12 was released in Apr 2019. The current version is 12.11.

The current version (11.10.0) has issues with create-react-app:

โฏ node --version
v11.10.0

โฏ npx create-react-app my-typescript-app --typescript
npx: installed 91 in 11.043s

Creating a new React app in /src/my-typescript-app.

Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts...

yarn add v1.13.0
[1/4] Resolving packages...
[2/4] Fetching packages...
error @typescript-eslint/[email protected]: The engine "node" is incompatible with this module. Expected version "^8.10.0 || ^10.13.0 || >=11.10.1". Got "11.10.0"
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Aborting installation.
  yarnpkg add --exact react react-dom react-scripts @types/node @types/react @types/react-dom @types/jest typescript --cwd /src/my-typescript-app has failed.

Deleting generated file... package.json
Deleting generated file... yarn.lock
Deleting my-typescript-app/ from /src
Done.

Expected version "^8.10.0 || ^10.13.0 || >=11.10.1". Got "11.10.0"

browserSync requires cumbersome work-arounds to function

I thought I would create an issue here to discuss a better workaround / solution for browserSync. Let me know if you are interested in discussing that. I can move the issue to my own fork if it is not something you want to pursue with me.

Currently when running gulp watch which triggers browserSync the connection is null-routed. I have a really ugly work around that I think we can improve upon.

Running npm start fails for electron projects

Hi,

I have a problem when I use npm start in a electron project. I am not sure if this is related to electron itself or if it is because of using npm in this docker setup, so I'm hoping to get some insight in that here. Specifically what happens is that npm start will try to run 'electron .' inside the current folder. This leads to an error:

Error: spawn /src/node_modules/electron/dist/electron ENOENT

However, running the following inside the root folder of the project works:

./node_modules/electron/dist/electron .

The ENOENT seems to indicate that the file to run could not be found, but as the folder I'm in is mounted in /src I am sure that this is not the case. Would greatly appreciate some insights on this. To reproduce simply do:

$ git clone https://github.com/electron/electron-api-demos
$ cd electron-api-demos
$ npm install
$ npm start

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.