servexyz / repo-genesis-cli

💥 Monolith relations across multiple repositories
https://www.npmjs.com/package/repo-genesis-cli
MIT License
1 stars 2 forks source link

logo

Getting Started

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

npm-starter

Use

Understand NPM Scripts Hierarchy

Parent scripts

The recommended way to use these parent commands is to point them at the child command that you'll use.
  • start - Primary entry point; parent to dev
  • build - Utility script; parent to build options
  • clean - Utility script; intended to be used for docker & node_modules
  • dev - Secondary entry point; parent to test
  • test - Secondary entry point; <np> friendly
  • ci - Utility script; parent to local and remote CI

Why parent & child scripts instead of inline?

By structuring it this way, you will be able to:
  • use consistent bash aliases across multiple projects
  • easily add/remove child scripts as needed
  • make reusable child scripts across multiple parent scripts

npm run start

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"
}

npm run 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"
}

npm run 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')"
}

npm run 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"
}

npm run 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"
}

npm run test

{
  "test": "npm run test:ava",
  "test:ava": "ava",
  "test:liveReloadedAva": "ava --watch"
}

npm run production

This is a standalone script which builds and runs your script with node

{
  "production": "npm run build && node build/main.js"
}

npm run 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"
}

Zsh/Bash Aliases

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'

Customizing

README.MD --> docs/NSTAR.MD

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)

Cleanup Scripts (Future Goal)

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)