A starter template for PWA and Native Ionic v3 projects, providing worflow & build management best pratices out-of-box:

• Aliases and environment variables support
• Documentation generation using Compodoc
• Unit testing and end-to-end (e2e)
• Continuous integration with Travis CI
• Automated dependency updates
• Standardized commit messages and automatic changelog generator

• [] Shared module
  • meumobi: Creating a shared module for Ionic App
• [] Simple Logging Service
  • A simple logging service for Angular 4
  • Angular's github: Add $log like functionality to Angular 2
• [] Lazy loading / Deep-linking
  • Ionic blog: Ionic and Lazy Loading Pt 1
  • Ionic blog: Ionic and Lazy Loading Pt 2

$ git clone https://github.com/meumobi/meu-starter.blank.ionic-v3.git [YOUR PROJECT NAME]
$ cd [YOUR PROJECT NAME]
[YOUR PROJECT NAME]$ rm CHANGELOG.md
[YOUR PROJECT NAME]$ git init
[YOUR PROJECT NAME]$ git add .
[YOUR PROJECT NAME]$ git commit -m "first commit"
[YOUR PROJECT NAME]$ git remote add origin ttps://github.com/[YOUR ACCOUNT]/[YOUR PROJECT NAME].git
[YOUR PROJECT NAME]$ git push -u origin master
[YOUR PROJECT NAME]$ npm run release -- --first-release
[YOUR PROJECT NAME]$ npm ci
[YOUR PROJECT NAME]$ ionic serve

• Signup/Signin on Travis CI and enable your new repository for Continuous Integration.
• Signup/Signin on Greenkeeper and enable Greenkeeper access for your new repository from your account page on section 'repo not listed?'

• Managing Aliases and environment variables in Ionic v3... preparing Ionic v4

• Compodoc: Getting Started

npm install --save-dev @compodoc/compodoc

Define script tasks for it in your package.json :

"scripts": {
  "docs:build": "./node_modules/.bin/compodoc -d ./docs/ -p ./tsconfig.json",
  "docs:serve": "./node_modules/.bin/compodoc -s -d ./docs"
}

and run it like a normal npm script, to generate documentation :

$ npm run docs:build

To serve the generated documentation:

$ npm run docs:serve

Open your browser and navigate to: http://localhost:8080

You can exclude files from the generated documentation by using 'exclude' in tsconfig.json:

  "exclude": [
    "./node_modules",
    "./temp/**/*.ts",
    "./src/environments/*.ts",
    "./src/services/**/*.ts",
    "**/*.spec.ts"
  ]

• Leif Wells's blog: Configure Existing Ionic Projects for Testing
• Unit Testing an Ionic2 project

The important modules are karma, jasmine and protractor:

• karma is our testing environment for unit testing.
• jasmine is the unit testing framework.
• protractor is our testing environment for our end-to-end tests.

The rest of the modules are utilities that allow this configuration to work.

$ npm run test

End-to-end tests explore the application as users experience it. In e2e testing, one process runs the real application and a second process runs protractor tests that simulate user behavior and assert that the application respond in the browser as expected.

$ npm run e2e

$ npm run test-coverage

In the ./coverage folder open index.html.

$ cd coverage/
$ python -m SimpleHTTPServer 8000

• Automated testing with Headless Chrome

• Continuous Build: a tool that checks periodically if the repository changed since the last build, and build/test if it did.
• Continuous Integration: a tool that takes Pull Requests and validate them against the latest head prior to making them visible.

If using feature branches, you should have the CI running automatically on those, and if the builds fail, don't merge them into master.

Using Travis, with each push we want to:

• run unit tests: npm run lint
• lint code: npm run test:headless
• generate build: npm run build
• run e2e (end to end) tests: xvfb-run npm run e2e

Travis CI connects to GitHub repositories out of the box. Navigate to (travis-ci.org) and sign in with your GitHub account. Navigate to your profile and you should see a list of your public repos from GitHub. Enable CI on targeted repo.

It was that simple, the last step for CI is to add a Travis CI configuration file to our project to tell Travis CI how to prepare environment for our app, on which branches to run CI build and which scripts to run on build.

To speed up CI build we use npm ci and package-lock.json.

As the official documentation says…

Headless Chrome is shipping in Chrome 59. It’s a way to run the Chrome browser in a headless environment. Essentially, running Chrome without chrome! It brings all modern web platform features provided by Chromium and the Blink rendering engine to the command line.

Caching with npm

cache:
  directories:
    - "node_modules"

npm install will still run on every build and will update/install any new packages added to your package.json file.

Thanks to julie-ng/angular-starter: Setup Travis CI

• use the Travis provided Chrome addon
• use the Travis provided xvfb wrapper around Chrome for E2E

• Testing Angular 2+ Apps with Jasmine and Karma
• Unit Testing with Angular
• Ionic project: Continuous Integration with Travis for gh-pages
• continuous integration | angular cli + firebase + travis ci
• Continuous Integration for Angular Projects with TravisCI
• Continuous Deployment for Ionic 2 to Firebase Hosting
• E2E (End-to-End) Testing in Ionic 2: An Introduction

We've selected Greenkeeper, against Dependabot, because it's free for github public project, inclusive for organization. The installation is pretty straight-forward, only need to signup on Greenkeeper, give autorization to connect to your github repository and follow instructions.

• Continuous everything with Angular, Travis CI, Firebase and Greenkeeper

standard-version automatically generates and updates CHANGELOG.md file with all the commits following Conventional Commits specification and correctly determines new version of our project.

The commit contains the following structural elements, to communicate intent to the consumers of your library:

• fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).
• feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).
• BREAKING CHANGE: a commit that has the text BREAKING CHANGE: at the beginning of its optional body or footer section introduces a breaking API change (correlating with MAJOR in semantic versioning). A breaking change can be part of commits of any type. e.g., a fix:, feat: & chore: types would all be valid, in addition to any other type.
• Others: commit types other than fix: and feat: are allowed, for example commitlint-config-conventional (based on the the Angular convention) recommends chore:, docs:, style:, refactor:, perf:, test:, and others. We also recommend improvement for commits that improve a current implementation without adding a new feature or fixing a bug. Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE, which is NOT recommended).

• RomainFallet/ionic-workflow-guide
• Robinyo/big-top