Skip to content

docs(arc-docs): detailed read me of arc-docs #110

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 55 additions & 37 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
# [ARC Angular](https://github.com/sourcefuse/angular-boilerplate)
[![Version](https://img.shields.io/badge/@angular/core-v14-brightgreen)](https://www.npmjs.com/package/@angular/cli/v/14.0.0)

[![Version](https://img.shields.io/badge/@angular/core-v14-brightgreen)](https://www.npmjs.com/package/@angular/cli/v/14.0.0)

<!-- DOCUMENTATION -->

## Description

This boilerplate uses multiple projects in single Angular workspace, which helps the users to develop shareable libraries, and for enterprises to use a "monorepo" development style, with a single repository and global configuration for all Angular projects. This boilerplate can also help in increasing productivity, reduce risks, and improve the quality of application.Duplication and redundant code can be avoided by using boilerplate approach.
This boilerplate uses multiple projects in single Angular workspace, which helps the users to develop shareable libraries, and for enterprises to use a "monorepo" development style, with a single repository and global configuration for all Angular projects. This boilerplate can also help in increasing productivity, reduce risks, and improve the quality of application.Duplication and redundant code can be avoided by using boilerplate approach.

## Usage

Expand All @@ -16,10 +16,10 @@
git clone https://github.com/sourcefuse/angular-boilerplate
```

### Step 2: Install the project dependencies by running the following command
### Step 2: Install the project dependencies by running the following command

```sh
npm install
npm install
```

After this, it will take a few minutes to set everything up, once that is done, you will see a folder structure generated like the following:-
Expand All @@ -40,23 +40,26 @@ BOILER-PLATE
├── README.md
└── tsconfig.json
```

Some predefined settings are initialised:-

1. A GitHub PR template is created inside: `.github`
2. Conventional commits are enabled using commitizen (`.cz-config.js`), commitlint (`commitlint-config.js`)
2. Conventional commits are enabled using commitizen (`.cz-config.js`), commitlint (`commitlint-config.js`)
and husky for githooks.
3. `.gitignore` for ignoring files from source code. Important for secure coding and keeping the repo clean
on SCM (git)
3. `.gitignore` for ignoring files from source code. Important for secure coding and keeping the repo clean
on SCM (git)
4. `package.json` and `package-lock.json` for npm to work.
5. The folder named `projects`: Projects will hold the multi application pattern and will always be
5. The folder named `projects`: Projects will hold the multi application pattern and will always be
completely independent.

#### Projects

##### Structure

```
PROJECTS
├── arc
├── arc-docs
├── arc-lib
│ └── src
│ └──lib
Expand All @@ -65,35 +68,48 @@ PROJECTS
│ ├── core
│ └── theme
├── (...other files)

```
##### Purpose
- As stated above, the boilerplate uses Multi-projects pattern to avoid duplication and is easy to maintain.
Here Boilerplate use "Projects" folder, which serves as a centralized location to organize and store project-related files and resources. For example:- An application can have multiple user portal :- admin-portal and super-admin-portal. In that case, the structure of the "Projects" folder can look like the following:-
```
PROJECTS
├── admin-portal
├── super-admin-portal
├── shared-lib
│ └── src
│ └──lib
│ ├── assets
│ ├── components
│ ├── core
│ └── theme
├── (...other files)
```

- Boilerplate allows users to Generate new applications at same workspace by using the following command:
```sh
ng generate application <application-name>

##### Purpose

- As stated above, the boilerplate uses Multi-projects pattern to avoid duplication and is easy to maintain.
Here Boilerplate use "Projects" folder, which serves as a centralized location to organize and store project-related files and resources. For example:- An application can have multiple user portal :- admin-portal and super-admin-portal. In that case, the structure of the "Projects" folder can look like the following:-

```
PROJECTS
├── admin-portal
├── super-admin-portal
├── shared-lib
│ └── src
│ └──lib
│ ├── assets
│ ├── components
│ ├── core
│ └── theme
├── (...other files)
```

1. Arc:
- This refers to the different applications inside single workspace sharing code.
- Boilerplate allows users to Generate new applications at same workspace by using the following command:

```sh
ng generate application <application-name>
```

1. Arc:

- This refers to the different applications inside single workspace sharing code.

2. Arc-Docs

- The arc-docs project is not explicitly detailed in the provided context. However, based on the structure and purpose of the boilerplate, we can infer that the arc-docs project is likely intended for documentation purposes related to the applications and libraries

For further reference you can refer [Here](/projects/arc-docs/Readme.md)

3. Arc-Lib

- This refers to the shared library which can include components, services, pipes, directives, and other modules that are shared among the applications in the workspace. By using a shared library, we avoid duplicating and using redundant code across, which can save time and effort.

2. Arc-Lib
- This refers to the shared library which can include components, services, pipes, directives, and other modules that are shared among the applications in the workspace. By using a shared library, we avoid duplicating and using redundant code across, which can save time and effort.

For further reference you can refer [Here](projects/arc-lib/README.md)

### Step 3: Setup the application to run
Expand All @@ -112,14 +128,15 @@ ng serve

You'll see a message saying Server is running at `http://localhost:4200/` Navigate to this URL. The application will automatically reload if you change any of the source files.

## Build the Application
## Build the Application

To build the project, run the following command:-

To build the project, run the following command:-

```sh
ng build
```
The build artifacts will be stored in the `dist/` directory.

The build artifacts will be stored in the `dist/` directory.

## Running unit tests

Expand All @@ -134,4 +151,5 @@ Run `ng e2e` to execute the end-to-end tests via a platform of your choice. To u
To get more help on the Angular CLI use `ng help` or go check out the [Angular CLI Overview and Command Reference](https://angular.io/cli) page.

## References

1. https://angular.io/guide/file-structure
28 changes: 28 additions & 0 deletions projects/arc-docs/Readme.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
<!-- DOCUMENTATION -->

# Arc- Docs

## Description

The documentation for the arc-docs project is not explicitly detailed in the provided context. However, based on the structure and purpose of the boilerplate, we can infer that the arc-docs project is likely intended for documentation purposes related to the applications and libraries within the Angular workspace.

## Purpose

The main objectives of the `arc-docs` project are:

- To offer clear and accessible documentation for each application and library within the ARC workspace.
- To provide user guides and best practices for developers working with the ARC Angular boilerplate.
- To facilitate the generation of API documentation for shared libraries using tools like Compodoc.
- To serve as a centralized resource for all project-related documentation.

## Getting Started

In a typical multi-project setup like this, a documentation project may serve the following purposes:

`Documentation Generation`: It may be used to generate and host documentation for the various applications and shared libraries (like arc-lib) within the workspace.

`User Guides`: It could provide user guides, tutorials, and usage examples for developers and users of the applications.

`Centralized Information` : It may serve as a centralized location for all documentation related to the projects in the workspace, making it easier for developers to find information.

If you need more precise information, please check the arc-docs folder in the project structure or refer to any related documentation that may have been included with the boilerplate.