node-starter
(aka NSTAR
) is a starting point for node modules and servers
Install
git clone https://github.com:servexyz/node-starter
npm install && npm start
Output
What you'll see after running
npm install && npm start
start
- Primary entry point; parent to devbuild
- Utility script; parent to build optionsclean
- Utility script; intended to be used for docker & node_modulesdev
- Secondary entry point; parent to testtest
- Secondary entry point; <np
> friendly ci
- Utility script; parent to local and remote CIstart
JS Developers are trained to npm install
and npm start
. In keeping with that tradition, start should point to your default developer experience.
{
"start": "npm run dev"
}
build
Run webpack for the specified environment. Read more about difference in webpack modes here
{
"build": "npm run build:prod",
"build:prod": "webpack --mode production --display minimal",
"build:dev": "webpack --mode development --display minimal"
}
clean
Remove build or docker containers.
{
"clean": "npm run clean:build",
"clean:build": "rm -Rf ./build",
"clean:docker": "docker rm -f $(docker ps -aqf 'name=node-starter')"
}
dev
Run your package with babel, nodemon or docker. Live reload watches changes and updatse your build for you automatically.
{
"dev": "npm run dev:liveReloadedModuleAndTests",
"dev:vanillaModule": "babel-node src/index.js",
"dev:liveReloadedModule": "nodemon --watch src/index.js --exec 'babel-node src/index.js'",
"dev:liveReloadedDocker": "npm-run-all -p docker:compose dev:liveReloadedModule docker:liveReload ",
"dev:liveReloadedModuleAndTests": "npm-run-all -s clean:build build test:liveReloadedAva"
}
docker
Compose your containers (see docker-compose.yml for more info) or live reload your docker containers (currently uses docker-live-reload)
{
"docker:liveReload": "npx docker-live-reload 'src/**/*' node-starter_server_1 /usr/src/server/src",
"docker:compose": "docker-compose up -d"
}
test
{
"test": "npm run test:ava",
"test:ava": "ava",
"test:liveReloadedAva": "ava --watch"
}
production
This is a standalone script which builds and runs your script with node
{
"production": "npm run build && node build/main.js"
}
ci
Run travis (CI) environment locally via trevor and test dependency vulnerabilities with snyk. The ci:remote
script is called by travis.yml
{
"ci": "npm-run-all -s build ci:local:timed:vuln",
"ci:snyk": "snyk test",
"ci:remote": "npm-run-all -s clean:build build test:ava",
"ci:local": "trevor",
"ci:local:timed": "npm run ci:local | gnomon --type=elapsed-total",
"ci:local:timed:vuln": "npm-run-all -p ci:snyk ci:local | gnomon --type=elapsed-total",
"ci:local:cache:install": "docker pull verdaccio/verdaccio",
"ci:local:cache:run": "docker run -it --rm --name verdaccio -p 4873:4873 verdaccio/verdaccio",
"ci:prepare": "npm install -g trevor gnomon"
}
Aliases you can import in your bash/zsh config to make it easier to run these NPM scripts
alias b='npm run build'
alias build='npm run build'
alias ci='npm run ci'
alias clean='npm run clean'
alias d='npm run dev'
alias dev='npm run dev'
alias n='npm start'
alias ni='npm install'
alias ns='npm start'
alias t='npm run test'
alias test='npm run test'
You'll notice that README.md is symlinked.
When forking, remove README.md. The NSTAR.md
file will still exist in docs (in case you want to reference any of this later)
As opposed to the common reject pattern, the goal of node-starter is to keep everything exposed. Meanwhile, you'll have the option to "cleanup" for specific use cases (CLI, library, server, container)