The Future of the Ionic CLI

The Ionic CLI should be your go to tool for building and maintaining Ionic applications.

It should provide:

A standardised project structure; code scaffolding; aliases; environment specific configuration; themes; logging; unit and e2e testing; and baked in best practices that have been discovered by the community over time.


One of the major projects that the Angular team delivered in the last few months is Schematics.

To quote Schematics

Schematics are generators that transform an existing file system. It can create files, refactor existing files, or move files around.



Very interesting. I’ll be able to take a closer look over the next couple of days. Is this your work?

-> Is this your work?

@jaydz Yes, Robinyo is my Brazilian soccer name :slight_smile:

Getting Started with @ionic-angular/schematics


    β”œβ”€β”€ <PROJECT_ROOT>
        └── /src
            └── /app                                  -  App Module
                β”œβ”€β”€ app.component.ts
                β”œβ”€β”€ app.html
                β”œβ”€β”€ app.module.ts
                β”œβ”€β”€ app.scss
                β”œβ”€β”€ main.ts
                └── /core                             - Core Feature Module (e.g., Singleton Services/Providers)
                    β”œβ”€β”€ core.module.ts                       
                    └── /logger
                        β”œβ”€β”€ console-logger.service.ts
                        β”œβ”€β”€ logger.service.ts                               
                └── /pages                            - Page (Component) Modules
                    └── /home
                └── /shared                           - Shared Feature Module (shared Components, Directives and Pipes)
            └── /assets
            └── /theme
                β”œβ”€β”€ variables.scss     
            β”œβ”€β”€ index.html
            β”œβ”€β”€ manifest.json
            β”œβ”€β”€ service-worker.js
        └── /resources
        └── /www
            └── /assets
            └── /build   
            β”œβ”€β”€ index.html
            β”œβ”€β”€ manifest.json
            β”œβ”€β”€ service-worker.js
        β”œβ”€β”€ .editorconfig
        β”œβ”€β”€ .gitignore
        β”œβ”€β”€ config.xml
        β”œβ”€β”€ ionic.config.json      
        β”œβ”€β”€ package.json
        β”œβ”€β”€ tsconfig.json
        β”œβ”€β”€ tslint.json             

Note: See this post re Shared Feature Module (Shared Common Modules) v Encapsulated Modules.

Generating a new Ionic Project


Generating Components


Your diagram as posted is ideal for an app with a small number of pages, like the Facebook or Instagram app. (They aren’t Ionic, but are good examples of well-programmed successful apps on few pages.) But for an app with many pages that could double as a PWA (like the Amazon app), it isn’t a good fit, and I’ve been struggling with that myself.

The standard Angular recipe in that case is to organize content by feature modules. The problem is that Angular’s routing fits well with feature modules, whereas Ionic’s routing-by-page does not. What I’ve ended up doing is splitting some features into ModuleWithProviders (a real thing) and β€œview” Modules (my own thing). Those modules both appear inside folders of the appropriate feature. I load the provider modules eagerly, and lazy load the view modules.

So it’s a specialization of the Angular features structure. Folders are organized by feature, and inside the features folder there are two types of features modules: providers and views.


I’ve just started using working with Schematics, open to suggestions (and pull requests) re any of the goals:

Have you seen these posts:

The asymmetry is that in Angular you lazy load modules. In Ionic you lazy load pages, and the modules follow. The suggestion in your first link is for a small app. The suggestions in your second link run afoul of the lazy loading asymmetry.


Another interesting post: