build: Use prettier for markdown
Stop ignoring .md files in prettier and fix existing issues.
This commit is contained in:
Ralph Hopman
+10
-10
@@ -8,19 +8,19 @@ In the interest of fostering an open and welcoming environment, we as contributo
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
- Using welcoming and inclusive language
|
||||
- Being respectful of differing viewpoints and experiences
|
||||
- Gracefully accepting constructive criticism
|
||||
- Focusing on what is best for the community
|
||||
- Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
- The use of sexualized language or imagery and unwelcome sexual attention or advances
|
||||
- Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
- Public or private harassment
|
||||
- Publishing others' private information, such as a physical or electronic address, without explicit permission
|
||||
- Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
|
||||
+21
-15
@@ -1,6 +1,6 @@
|
||||
# Commit Message Conventions
|
||||
|
||||
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
|
||||
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**:
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
@@ -17,42 +17,48 @@ Any line of the commit message cannot be longer than 100 characters! This allows
|
||||
The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
|
||||
|
||||
### Revert
|
||||
|
||||
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the commit id of the commit being reverted.
|
||||
|
||||
### Type
|
||||
|
||||
Must be one of the following:
|
||||
|
||||
* **build**: Changes that affect the build system or external dependencies (example scopes: npm, webpack etc)
|
||||
* **chore**: Other changes that don't modify src or test files
|
||||
* **ci**: Changes to CI configuration files and scripts (example scopes: Travis etc)
|
||||
* **docs**: Documentation only changes
|
||||
* **feat**: A new feature
|
||||
* **fix**: A bug fix
|
||||
* **perf**: A code change that improves performance
|
||||
* **refactor**: A code change that neither fixes a bug nor adds a feature
|
||||
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons etc)
|
||||
* **test**: Adding missing tests or correcting existing tests
|
||||
- **build**: Changes that affect the build system or external dependencies (example scopes: npm, webpack etc)
|
||||
- **chore**: Other changes that don't modify src or test files
|
||||
- **ci**: Changes to CI configuration files and scripts (example scopes: Travis etc)
|
||||
- **docs**: Documentation only changes
|
||||
- **feat**: A new feature
|
||||
- **fix**: A bug fix
|
||||
- **perf**: A code change that improves performance
|
||||
- **refactor**: A code change that neither fixes a bug nor adds a feature
|
||||
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons etc)
|
||||
- **test**: Adding missing tests or correcting existing tests
|
||||
|
||||
### Scope
|
||||
|
||||
The scope could be anything specifying place of the commit change or empty. (example: main.scss, login etc)
|
||||
|
||||
### Subject
|
||||
|
||||
The subject contains a brief and clear description of the change:
|
||||
|
||||
* use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
* don't capitalize the first letter
|
||||
* no dot (.) at the end
|
||||
- use the imperative, present tense: "change" not "changed" nor "changes"
|
||||
- don't capitalize the first letter
|
||||
- no dot (.) at the end
|
||||
|
||||
### Body
|
||||
|
||||
Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
|
||||
|
||||
### Footer
|
||||
|
||||
The footer should contain any information about **Breaking Changes** and is also the place to reference GitHub issues that this commit **Closes**.
|
||||
|
||||
**Breaking Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. The rest of the commit message is then used for this.
|
||||
|
||||
|
||||
## Example Commit Message
|
||||
|
||||
```
|
||||
feat: Summarize changes in around 50 characters or less
|
||||
|
||||
|
||||
+60
-21
@@ -22,127 +22,166 @@ Each active repository has its own channel to direct questions to. Also join the
|
||||
|
||||
Remember that this is an inclusive community, committed to creating a safe, positive environment. See the whole [Code of Conduct](CODE_OF_CONDUCT.md) and please follow it in all your interactions with the project.
|
||||
|
||||
|
||||
## Submitting or Requesting an Issue/Enhancement
|
||||
|
||||
### Best Practices for reporting or requesting for Issues/Enhancements:
|
||||
- Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
|
||||
- Follow the Issue Template while creating the issue.
|
||||
- Include Screenshots if any (specially for UI related issues).
|
||||
- For UI enhancements or workflows, include mockups to get a clear idea.
|
||||
|
||||
- Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
|
||||
- Follow the Issue Template while creating the issue.
|
||||
- Include Screenshots if any (specially for UI related issues).
|
||||
- For UI enhancements or workflows, include mockups to get a clear idea.
|
||||
|
||||
### Best Practices for getting assigned to work on an Issue/Enhancement:
|
||||
|
||||
- If you would like to work on an issue, inform in the issue ticket by commenting on it.
|
||||
- Please be sure that you are able to reproduce the issue, before working on it. If not, please ask for clarification by commenting or asking the issue creator.
|
||||
|
||||
**Note:** Please do not work on an issue which is already being worked on by another contributor. We don't encourage creating multiple pull requests for the same issue. Also, please allow the assigned person at least 2 days to work on the issue (The time might vary depending on the difficulty). If there is no progress after the deadline, please comment on the issue asking the contributor whether he/she is still working on it. If there is no reply, then feel free to work on the issue.
|
||||
|
||||
|
||||
## Submitting a Pull Request
|
||||
|
||||
### Best Practices to send Pull Requests:
|
||||
- Fork the [project](https://github.com/openMF/web-app) on GitHub
|
||||
- Clone the project locally into your system.
|
||||
|
||||
- Fork the [project](https://github.com/openMF/web-app) on GitHub
|
||||
- Clone the project locally into your system.
|
||||
|
||||
```
|
||||
git clone https://github.com/your-username/web-app.git
|
||||
```
|
||||
- Make sure you are in the `master` branch.
|
||||
|
||||
- Make sure you are in the `master` branch.
|
||||
|
||||
```
|
||||
git checkout master
|
||||
```
|
||||
- Create a new branch with a meaningful name before adding and committing your changes.
|
||||
|
||||
- Create a new branch with a meaningful name before adding and committing your changes.
|
||||
|
||||
```
|
||||
git checkout -b branch-name
|
||||
```
|
||||
- Add the files you changed. (avoid using `git add .`)
|
||||
|
||||
- Add the files you changed. (avoid using `git add .`)
|
||||
|
||||
```
|
||||
git add file-name
|
||||
```
|
||||
- Follow the style conventions for a [meaningful commit message](COMMIT_MESSAGE.md).
|
||||
|
||||
- Follow the style conventions for a [meaningful commit message](COMMIT_MESSAGE.md).
|
||||
|
||||
```
|
||||
git commit
|
||||
```
|
||||
- If you forgot to add some changes, you can edit your previous commit message.
|
||||
|
||||
- If you forgot to add some changes, you can edit your previous commit message.
|
||||
|
||||
```
|
||||
git commit --amend
|
||||
```
|
||||
- Squash multiple commits to a single commit. (example: squash last two commits done on this branch into one)
|
||||
|
||||
- Squash multiple commits to a single commit. (example: squash last two commits done on this branch into one)
|
||||
|
||||
```
|
||||
git rebase --interactive HEAD~2
|
||||
```
|
||||
- Push this branch to your remote repository on GitHub.
|
||||
|
||||
- Push this branch to your remote repository on GitHub.
|
||||
|
||||
```
|
||||
git push origin branch-name
|
||||
```
|
||||
- If any of the squashed commits have already been pushed to your remote repository, you need to do a force push.
|
||||
|
||||
- If any of the squashed commits have already been pushed to your remote repository, you need to do a force push.
|
||||
|
||||
```
|
||||
git push origin remote-branch-name --force
|
||||
```
|
||||
- Follow the Pull request template and submit a pull request with a motive for your change and the method you used to achieve it to be merged with the `master` branch.
|
||||
- If you can, please submit the pull request with the fix or improvements including tests.
|
||||
- During review, if you are requested to make changes, rebase your branch and squash the multiple commits into one. Once you push these changes the pull request will edit automatically.
|
||||
|
||||
- Follow the Pull request template and submit a pull request with a motive for your change and the method you used to achieve it to be merged with the `master` branch.
|
||||
- If you can, please submit the pull request with the fix or improvements including tests.
|
||||
- During review, if you are requested to make changes, rebase your branch and squash the multiple commits into one. Once you push these changes the pull request will edit automatically.
|
||||
|
||||
## Configuring remotes
|
||||
|
||||
When a repository is cloned, it has a default remote called `origin` that points to your fork on GitHub, not the original repository it was forked from. To keep track of the original repository, you should add another remote called `upstream`.
|
||||
|
||||
1. Set the `upstream`.
|
||||
|
||||
```
|
||||
git remote add upstream https://github.com/openMF/web-app.git
|
||||
```
|
||||
|
||||
2. Use `git remote -v` to check the status. The output must be something like this:
|
||||
|
||||
```
|
||||
> origin https://github.com/your-username/web-app.git (fetch)
|
||||
> origin https://github.com/your-username/web-app.git (push)
|
||||
> upstream https://github.com/openMF/web-app.git (fetch)
|
||||
> upstream https://github.com/openMF/web-app.git (push)
|
||||
```
|
||||
|
||||
3. To update your local copy with remote changes, run the following: (This will give you an exact copy of the current remote. You should not have any local changes on your master branch, if you do, use rebase instead.)
|
||||
|
||||
```
|
||||
git fetch upstream
|
||||
git checkout master
|
||||
git merge upstream/master
|
||||
```
|
||||
|
||||
4. Push these merged changes to the master branch on your fork. Ensure to pull in upstream changes regularly to keep your forked repository up to date.
|
||||
|
||||
```
|
||||
git push origin master
|
||||
```
|
||||
|
||||
5. Switch to the branch you are using for some piece of work.
|
||||
|
||||
```
|
||||
git checkout branch-name
|
||||
```
|
||||
|
||||
6. Rebase your branch, which means, take in all latest changes and replay your work in the branch on top of this - this produces cleaner versions/history.
|
||||
|
||||
```
|
||||
git rebase master
|
||||
```
|
||||
|
||||
7. Push the final changes when you're ready.
|
||||
|
||||
```
|
||||
git push origin branch-name
|
||||
```
|
||||
|
||||
## After your Pull Request is merged
|
||||
|
||||
After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository.
|
||||
|
||||
1. Delete the remote branch on GitHub.
|
||||
|
||||
```
|
||||
git push origin --delete branch-name
|
||||
```
|
||||
|
||||
2. Checkout the master branch.
|
||||
|
||||
```
|
||||
git checkout master
|
||||
```
|
||||
|
||||
3. Delete the local branch.
|
||||
|
||||
```
|
||||
git branch -D branch-name
|
||||
```
|
||||
|
||||
4. Update your master branch with the latest upstream version.
|
||||
|
||||
```
|
||||
git pull upstream master
|
||||
```
|
||||
|
||||
|
||||
## Skipping a Travis CI Build
|
||||
|
||||
If running a build is not required for a particular commit (in some cases like an update to README.md), add [ci skip] or [skip ci] to the git commit message. Commits that have [ci skip] or [skip ci] anywhere in the commit messages are ignored by Travis CI.
|
||||
|
||||
|
||||
That's it! Thank you for your contribution!
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
---
|
||||
name: Bug Report
|
||||
about: Create a report to help us improve
|
||||
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Provide a brief overview of the enhancement or issue.
|
||||
|
||||
## Steps to Reproduce
|
||||
|
||||
Please add as much detail as possible to reproduce the error/issue.
|
||||
Don't assume the reader knows anything about the Mifos X Web App.
|
||||
|
||||
@@ -16,6 +17,7 @@ Don't assume the reader knows anything about the Mifos X Web App.
|
||||
## Actual Behaviour
|
||||
|
||||
## Settings
|
||||
|
||||
- Mifos X version:
|
||||
- Browser used:
|
||||
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
name: Feature Request
|
||||
about: Suggest an idea for this project
|
||||
|
||||
---
|
||||
|
||||
**Is your feature request related to a problem? Please describe.**
|
||||
|
||||
@@ -1,7 +1,6 @@
|
||||
---
|
||||
name: User Story Template
|
||||
about: Template for basic user story
|
||||
|
||||
---
|
||||
|
||||
**Goal:**
|
||||
@@ -11,18 +10,17 @@ i.e.
|
||||
|
||||
As DevOps I want Health liveness Probe on the microservice so that the health of the service can be monitored.
|
||||
|
||||
|
||||
**Tasks:**
|
||||
i.e.
|
||||
1. Add negative use-cases to Unit tests
|
||||
2. Add Integration tests
|
||||
3.
|
||||
i.e.
|
||||
|
||||
1. Add negative use-cases to Unit tests
|
||||
2. Add Integration tests
|
||||
3.
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
- [ ] [LIST ITEMS]
|
||||
i.e.
|
||||
- [ ] [LIST ITEMS]
|
||||
i.e.
|
||||
|
||||
- [ ] Negative use-cases for Unit Tests in the "common streaming library"
|
||||
- [ ] Integration tests in the "common streaming library"
|
||||
- [ ] Negative use-cases for Unit Tests in the "common streaming library"
|
||||
- [ ] Integration tests in the "common streaming library"
|
||||
|
||||
@@ -1,12 +1,15 @@
|
||||
## Description
|
||||
|
||||
Describe the changes made and why they were made instead of how they were made. List any dependencies that are required for this change.
|
||||
|
||||
## Related issues and discussion
|
||||
|
||||
#{Issue Number}
|
||||
|
||||
## Screenshots, if any
|
||||
|
||||
## Checklist
|
||||
|
||||
Please make sure these boxes are checked before submitting your pull request - thanks!
|
||||
|
||||
- [ ] If you have multiple commits please combine them into one commit by squashing them.
|
||||
|
||||
@@ -4,6 +4,5 @@
|
||||
*.html
|
||||
*.js
|
||||
*.json
|
||||
*.md
|
||||
*.ts
|
||||
*.yml
|
||||
|
||||
@@ -4,26 +4,26 @@ Mifos X Web App is the revamped version of the Mifos X Community App, an effecti
|
||||
|
||||
It is a Single-Page App (SPA) written in standard web technologies [HTML5](http://whatwg.org/html), [SCSS](http://sass-lang.com) and [TypeScript](http://www.typescriptlang.org). It leverages the popular [Angular](https://angular.io/) framework and [Angular Material](https://material.angular.io/) for material design components.
|
||||
|
||||
|
||||
## Getting started using
|
||||
|
||||
The latest code is continuously deployed at https://openmf.github.io/web-app/ whenever a PR is merged into the master branch.
|
||||
|
||||
|
||||
## Getting started developing
|
||||
|
||||
1. Ensure you have the following installed in your system:
|
||||
|
||||
[`git`](https://git-scm.com/downloads)
|
||||
[`git`](https://git-scm.com/downloads)
|
||||
|
||||
[`npm`](https://nodejs.org/en/download/)
|
||||
[`npm`](https://nodejs.org/en/download/)
|
||||
|
||||
2. Install [angular-cli](https://github.com/angular/angular-cli) globally.
|
||||
|
||||
```
|
||||
npm install -g @angular/cli@14.2.12
|
||||
```
|
||||
|
||||
3. Clone the project locally into your system.
|
||||
|
||||
```
|
||||
git clone https://github.com/openMF/web-app.git
|
||||
```
|
||||
@@ -31,11 +31,13 @@ git clone https://github.com/openMF/web-app.git
|
||||
4. `cd` into project root directory and make sure you are on the master branch.
|
||||
|
||||
5. Install the dependencies.
|
||||
|
||||
```
|
||||
npm install
|
||||
```
|
||||
|
||||
6. To preview the app, run the following command and navigate to `http://localhost:4200/`.
|
||||
|
||||
```
|
||||
ng serve
|
||||
```
|
||||
@@ -67,7 +69,6 @@ Run `npm run build:prod` to build a production artifacts Instead.
|
||||
To get more help on the Angular CLI use `ng help` or go check out the
|
||||
[Angular-CLI README](https://github.com/angular/angular-cli).
|
||||
|
||||
|
||||
## Setting up a local server
|
||||
|
||||
Follow the given instructions for your operating system to setup a local server for the Mifos X platform.
|
||||
@@ -82,12 +83,14 @@ By default OAuth2 is disabled. To enable it, change the value of oauth.enabled p
|
||||
|
||||
### Docker
|
||||
|
||||
|
||||
To locally build this Docker image from source (after `git clone` this repo), run:
|
||||
|
||||
```
|
||||
docker build -t openmf/web-app:latest .
|
||||
```
|
||||
|
||||
You can then run a Docker Container from the image above like this:
|
||||
|
||||
```
|
||||
docker run -d -p 4200:80 openmf/web-app:latest
|
||||
```
|
||||
@@ -95,6 +98,7 @@ docker run -d -p 4200:80 openmf/web-app:latest
|
||||
Access the webapp on http://localhost:4200 in your browser.
|
||||
|
||||
### Docker compose
|
||||
|
||||
It is possible to do a 'one-touch' installation of Mifos X Web App using containers (AKA "Docker").
|
||||
Fineract now packs the Mifos community-app web UI in it's docker deploy.
|
||||
|
||||
@@ -114,10 +118,13 @@ You can also setup different configurations for the MifosX Web App using environ
|
||||
1. Use environment variables (best choice if you run with Docker Compose):
|
||||
|
||||
Fineract backend settings
|
||||
|
||||
```
|
||||
FINERACT_API_URLS
|
||||
```
|
||||
|
||||
Value to set a Fineract server list (environments) to be used, Default value:
|
||||
|
||||
```
|
||||
https://dev.mifos.io,https://demo.mifos.io,https://qa.mifos.io,https://staging.mifos.io,https://mobile.mifos.io,https://demo.fineract.dev,https://localhost:8443
|
||||
```
|
||||
@@ -125,7 +132,9 @@ https://dev.mifos.io,https://demo.mifos.io,https://qa.mifos.io,https://staging.m
|
||||
```
|
||||
FINERACT_API_URL
|
||||
```
|
||||
|
||||
Default value used from the Fineract server list. Default value:
|
||||
|
||||
```
|
||||
https://localhost:8443
|
||||
```
|
||||
@@ -133,7 +142,9 @@ https://localhost:8443
|
||||
```
|
||||
FINERACT_PLATFORM_TENANT_IDENTIFIER
|
||||
```
|
||||
|
||||
Fineract Tenant identifier to be used by default, It must be aligned with the Fineract `tenants` table. Default value:
|
||||
|
||||
```
|
||||
default
|
||||
```
|
||||
@@ -141,75 +152,78 @@ default
|
||||
```
|
||||
FINERACT_PLATFORM_TENANTS_IDENTIFIER
|
||||
```
|
||||
|
||||
Fineract Tenant identifier list to be used, Those must be aligned with the Fineract `tenants` table.
|
||||
|
||||
|
||||
Setting for Languages (i18n) still under development
|
||||
|
||||
```
|
||||
MIFOS_DEFAULT_LANGUAGE=en-US
|
||||
```
|
||||
|
||||
```
|
||||
MIFOS_SUPPORTED_LANGUAGES=cs-CS,de-DE,en-US,es-MX,fr-FR,it-IT,ko-KO,lt-LT,lv-LV,ne-NE,pt-PT,sw-SW
|
||||
```
|
||||
|
||||
These are the Language available now:
|
||||
|
||||
```
|
||||
MIFOS_SESSION_IDLE_TIMEOUT=300000
|
||||
```
|
||||
|
||||
Time in milliseconds for Session idle timeout, default 300000 seconds
|
||||
|
||||
|
||||
| Language | Code | File |
|
||||
|:----------:|:----:|:----------:|
|
||||
| Czech | cs | cs-CS.json |
|
||||
| German | de | de-DE.json |
|
||||
| English | en | en-US.json |
|
||||
| Spanish | es | es-MX.json |
|
||||
| French | fr | fr-FR.json |
|
||||
| Italian | it | it-IT.json |
|
||||
| Korean | ko | ko-KO.json |
|
||||
| :--------: | :--: | :--------: |
|
||||
| Czech | cs | cs-CS.json |
|
||||
| German | de | de-DE.json |
|
||||
| English | en | en-US.json |
|
||||
| Spanish | es | es-MX.json |
|
||||
| French | fr | fr-FR.json |
|
||||
| Italian | it | it-IT.json |
|
||||
| Korean | ko | ko-KO.json |
|
||||
| Lithuanian | li | li-LI.json |
|
||||
| Latvian | lv | lv-LV.json |
|
||||
| Nepali | ne | ne-NE.json |
|
||||
| Latvian | lv | lv-LV.json |
|
||||
| Nepali | ne | ne-NE.json |
|
||||
| Portuguese | pt | pt-PT.json |
|
||||
| Swahili | sw | sw-SW.json |
|
||||
|
||||
| Swahili | sw | sw-SW.json |
|
||||
|
||||
Setting for applying the Client preload in the Clients view, Default true
|
||||
|
||||
```
|
||||
MIFOS_PRELOAD_CLIENTS=false
|
||||
```
|
||||
|
||||
|
||||
Setting for exporting report table to CSV file using this field delimiter
|
||||
|
||||
```
|
||||
MIFOS_DEFAULT_CHAR_DELIMITER=,
|
||||
```
|
||||
|
||||
|
||||
Setting for Wait time in seconds for reading the user notifications, Default 60 seconds
|
||||
|
||||
```
|
||||
MIFOS_WAIT_TIME_FOR_NOTIFICATIONS=60
|
||||
```
|
||||
|
||||
Setting for Wait time in seconds for reading the COB Catch-Up status, Default 30 seconds
|
||||
|
||||
```
|
||||
MIFOS_WAIT_TIME_FOR_CATCHUP=30
|
||||
```
|
||||
|
||||
|
||||
Setting for display or hide the Tenant selector in the Login view (mainly for Production environments and for security reasons), Default true
|
||||
|
||||
```
|
||||
MIFOS_DISPLAY_TENANT_SELECTOR=false
|
||||
```
|
||||
|
||||
|
||||
Setting for display or hide the Backend info (url) in the footer part (mainly for security reasons), Default true
|
||||
|
||||
```
|
||||
MIFOS_DISPLAY_BACKEND_INFO=false
|
||||
```
|
||||
|
||||
|
||||
For more information look the env.sample file in the root directory of the project
|
||||
|
||||
## Want to help? [](https://github.com/openMF/web-app/issues)
|
||||
|
||||
@@ -2,4 +2,3 @@
|
||||
|
||||
This project does not come with any analytics library.
|
||||
Should you decide to use one, you may want to consider [Angulartics2](https://github.com/angulartics/angulartics2).
|
||||
|
||||
|
||||
@@ -14,11 +14,12 @@ we also have setup a backend proxy to redirect API calls to whatever URL and por
|
||||
In the root folder you will find a `proxy.conf.js`, containing the backend proxy configuration.
|
||||
|
||||
The interesting part is there:
|
||||
|
||||
```js
|
||||
const proxyConfig = [
|
||||
{
|
||||
context: '/api',
|
||||
pathRewrite: {'^/api': ''},
|
||||
pathRewrite: { '^/api': '' },
|
||||
target: 'http://api.icndb.com',
|
||||
changeOrigin: true
|
||||
}
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
[Angular](https://angular.io) (aka Angular 2, 4, 5, 6...) is a new framework completely rewritten from the ground up,
|
||||
replacing the now well-known [AngularJS](https://angularjs.org) framework (aka Angular 1.x).
|
||||
|
||||
More that just a framework, Angular should now be considered as a whole *platform* which comes with a complete set of
|
||||
More that just a framework, Angular should now be considered as a whole _platform_ which comes with a complete set of
|
||||
tools, like its own [CLI](https://github.com/angular/angular-cli), [debug utilities](https://augury.angular.io) or
|
||||
[performance tools](https://github.com/angular/angular/tree/master/packages/benchpress).
|
||||
|
||||
@@ -52,33 +52,33 @@ You will essentially find here a list of good starting points to learn more on t
|
||||
|
||||
#### Reactive programming
|
||||
|
||||
You may not be aware of it, but Angular is now a *reactive system* by design.
|
||||
You may not be aware of it, but Angular is now a _reactive system_ by design.
|
||||
Although you are not forced to use reactive programming patterns, they make the core of the framework and it is
|
||||
definitely recommended to learn them if you want to leverage the best of Angular.
|
||||
|
||||
Angular uses [RxJS](http://reactivex.io/rxjs/) to implement the *Observable* pattern.
|
||||
Angular uses [RxJS](http://reactivex.io/rxjs/) to implement the _Observable_ pattern.
|
||||
|
||||
> An *Observable* is a stream of asynchronous events that can be processed with array-like operators.
|
||||
> An _Observable_ is a stream of asynchronous events that can be processed with array-like operators.
|
||||
|
||||
##### From promises to observables
|
||||
|
||||
While AngularJS used to rely heavily on [*Promises*](https://docs.angularjs.org/api/ng/service/$q) to handle
|
||||
asynchronous events, *Observables* are now used instead in Angular. Even though in specific cases like for HTTP
|
||||
requests, an *Observable* can be converted into a *Promise*, it is recommended to embrace the new paradigm as it can a
|
||||
lot more than *Promises*, with way less code. This transition is also explained in the
|
||||
While AngularJS used to rely heavily on [_Promises_](https://docs.angularjs.org/api/ng/service/$q) to handle
|
||||
asynchronous events, _Observables_ are now used instead in Angular. Even though in specific cases like for HTTP
|
||||
requests, an _Observable_ can be converted into a _Promise_, it is recommended to embrace the new paradigm as it can a
|
||||
lot more than _Promises_, with way less code. This transition is also explained in the
|
||||
[Angular tutorial](https://angular.io/tutorial/toh-pt6#!%23observables).
|
||||
Once you have made the switch, you will never look back again.
|
||||
|
||||
##### Learning references
|
||||
|
||||
- [What is reactive programming?](http://paulstovell.com/blog/reactive-programming), explained nicely through a simple
|
||||
imaged story *(5 min)*
|
||||
imaged story _(5 min)_
|
||||
|
||||
- [The introduction to reactive programming you've been missing](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754),
|
||||
the title says it all *(30 min)*
|
||||
the title says it all _(30 min)_
|
||||
|
||||
- [Functional reactive programming for Angular 2 developers](http://blog.angular-university.io/functional-reactive-programming-for-angular-2-developers-rxjs-and-observables/),
|
||||
see the functional reactive programming principles in practice with Angular *(15 min)*
|
||||
see the functional reactive programming principles in practice with Angular _(15 min)_
|
||||
|
||||
- [RxMarbles](http://rxmarbles.com), a graphical representation of Rx operators that greatly help to understand their
|
||||
usage
|
||||
@@ -95,13 +95,13 @@ with substantial performance improvements.
|
||||
**Wait, then why the Angular documentation have mention of a
|
||||
[two-way binding syntax](https://angular.io/guide/template-syntax#binding-syntax-an-overview)?**
|
||||
|
||||
If you look closely, the new two-way binding syntax is just syntactic sugar to combine two *one-way* bindings (a
|
||||
*property* and *event* binding), keeping the data flow unidirectional.
|
||||
If you look closely, the new two-way binding syntax is just syntactic sugar to combine two _one-way_ bindings (a
|
||||
_property_ and _event_ binding), keeping the data flow unidirectional.
|
||||
|
||||
This change is really important, as it was often the cause of performance issues with AngularJS, and it one of the
|
||||
pillars enabling better performance in new Angular apps.
|
||||
|
||||
While Angular tries to stay *pattern-agnostic* and can be used with conventional MV* patterns, it was designed with
|
||||
While Angular tries to stay _pattern-agnostic_ and can be used with conventional MV\* patterns, it was designed with
|
||||
reactive programming in mind and really shines when used with reactive data flow patterns like
|
||||
[redux](http://redux.js.org/docs/basics/DataFlow.html),
|
||||
[Flux](https://facebook.github.io/flux/docs/in-depth-overview.html#content) or
|
||||
@@ -112,25 +112,25 @@ reactive programming in mind and really shines when used with reactive data flow
|
||||
As applications grow in size, keeping track of the all its individual components state and data flows can become
|
||||
tedious, and tend to be difficult to manage and debug.
|
||||
|
||||
The main goal of using a centralized state management is to make state changes *predictable* by imposing certain
|
||||
restrictions on how and when updates can happen, using *unidirectional data flow*.
|
||||
The main goal of using a centralized state management is to make state changes _predictable_ by imposing certain
|
||||
restrictions on how and when updates can happen, using _unidirectional data flow_.
|
||||
|
||||
This approach was first made popular with React with introduction of the
|
||||
[Flux](https://facebook.github.io/flux/docs/in-depth-overview.html#content) architecture. Many libraries emerged then
|
||||
trying to adapt and refine the original concept, and one of these gained massive popularity by providing a simpler,
|
||||
elegant alternative: [Redux](http://redux.js.org/docs/basics/DataFlow.html).
|
||||
|
||||
Redux is at the same time a library (with the big *R*) and a design pattern (with the little *r*), the latter being
|
||||
Redux is at the same time a library (with the big _R_) and a design pattern (with the little _r_), the latter being
|
||||
framework-agnostic and working very well with Angular.
|
||||
|
||||
The *redux* design pattern is based on these [3 principles](http://redux.js.org/docs/introduction/ThreePrinciples.html):
|
||||
The _redux_ design pattern is based on these [3 principles](http://redux.js.org/docs/introduction/ThreePrinciples.html):
|
||||
|
||||
- The application state is a *single immutable* data structure
|
||||
- A state change is triggered by an *action*, an object describing what happened
|
||||
- Pure functions called *reducers* take the previous state and the next action to compute the new state
|
||||
- The application state is a _single immutable_ data structure
|
||||
- A state change is triggered by an _action_, an object describing what happened
|
||||
- Pure functions called _reducers_ take the previous state and the next action to compute the new state
|
||||
|
||||
The core concepts behind these principles are nicely explained in
|
||||
[this example](http://redux.js.org/docs/introduction/CoreConcepts.html) *(3 min)*.
|
||||
[this example](http://redux.js.org/docs/introduction/CoreConcepts.html) _(3 min)_.
|
||||
|
||||
##### Which library to use?
|
||||
|
||||
@@ -142,10 +142,10 @@ utilities.
|
||||
Here are some resources to get started:
|
||||
|
||||
- [Build a better Angular 2 application with redux and ngrx](http://onehungrymind.com/build-better-angular-2-application-redux-ngrx/),
|
||||
a nice tutorial for @ngrx/store *(30 min)*
|
||||
a nice tutorial for @ngrx/store _(30 min)_
|
||||
|
||||
- [Comprehensive introduction to @ngrx/store](https://gist.github.com/btroncone/a6e4347326749f938510), an in-depth
|
||||
walkthrough to this library usage in Angular *(60 min)*
|
||||
walkthrough to this library usage in Angular _(60 min)_
|
||||
|
||||
##### When to use it?
|
||||
|
||||
|
||||
@@ -18,15 +18,15 @@ These tests use [Protractor](https://github.com/angular/protractor), which is a
|
||||
|
||||
## Page objects
|
||||
|
||||
E2E tests should follow the *[Page Object](https://github.com/SeleniumHQ/selenium/wiki/PageObjects)* pattern.
|
||||
E2E tests should follow the _[Page Object](https://github.com/SeleniumHQ/selenium/wiki/PageObjects)_ pattern.
|
||||
|
||||
#### What is a page object?
|
||||
|
||||
A page object:
|
||||
|
||||
- Models the objects on a page under test:
|
||||
* *Properties* wrap page elements
|
||||
* *Methods* wrap code that interacts with the page elements
|
||||
- _Properties_ wrap page elements
|
||||
- _Methods_ wrap code that interacts with the page elements
|
||||
- Simplifies the test scripts
|
||||
- Reduces the amount of duplicated code
|
||||
|
||||
@@ -61,7 +61,7 @@ export class LoginPage {
|
||||
import { LoginPage } from './login.po';
|
||||
|
||||
describe('Login', () => {
|
||||
let page: LoginPage ;
|
||||
let page: LoginPage;
|
||||
|
||||
beforeEach(() => {
|
||||
page = new LoginPage();
|
||||
|
||||
@@ -13,8 +13,8 @@
|
||||
- Use double quotes `"` around attribute values in tags
|
||||
- Use a new line for every block, list, or table element, and indent every such child element
|
||||
- Clearly Separate structure (HTML) from presentation (CSS) from behavior (JavaScript):
|
||||
* Never use inline CSS or JavaScript
|
||||
* Keep any logic out of the HTML
|
||||
- Never use inline CSS or JavaScript
|
||||
- Keep any logic out of the HTML
|
||||
- `type` attribute for stylesheets and script tags should be omitted
|
||||
|
||||
## Common pitfalls
|
||||
@@ -22,8 +22,8 @@
|
||||
- **Block**-type tags cannot be nested inside **inline**-type tags: a `<div>` tag cannot be nested in a `<span>`.
|
||||
This rule also applies regarding the `display` value of an element.
|
||||
- HTML is **not** XML: empty tags cannot be self-closing and will result in improper results
|
||||
* `<div/>` will be interpreted as a simple `<div>` without closing tag!
|
||||
* The only tags that allows self-closing are the one that does not require a closing tag in first place:
|
||||
- `<div/>` will be interpreted as a simple `<div>` without closing tag!
|
||||
- The only tags that allows self-closing are the one that does not require a closing tag in first place:
|
||||
these are the void elements that do not not accept content `<br>`, `<hr>`, `<img>`, `<input>`, `<meta>`, `<link>`
|
||||
(and others).
|
||||
|
||||
@@ -37,4 +37,3 @@ Only use inline templates sparingly in very simple components with less than 3 l
|
||||
## Enforcement
|
||||
|
||||
Coding rules enforcement and basic sanity checks are done in this project by [HTMLHint](http://htmlhint.com).
|
||||
|
||||
|
||||
+23
-20
@@ -3,11 +3,11 @@
|
||||
[Sass](http://sass-lang.com) is a superset of CSS, which brings a lot of developer candy to help scaling CSS in large
|
||||
projects and keeping it maintainable.
|
||||
|
||||
The main benefits of using Sass over plain CSS are *variables*, *nesting* and *mixins*, see the
|
||||
The main benefits of using Sass over plain CSS are _variables_, _nesting_ and _mixins_, see the
|
||||
[basics guide](http://sass-lang.com/guide) for more details.
|
||||
|
||||
> Note that this project use the newer, CSS-compatible **SCSS** syntax over the old
|
||||
[indented syntax](http://sass-lang.com/documentation/file.INDENTED_SYNTAX.html).
|
||||
> [indented syntax](http://sass-lang.com/documentation/file.INDENTED_SYNTAX.html).
|
||||
|
||||
## Naming conventions
|
||||
|
||||
@@ -18,6 +18,7 @@ The main benefits of using Sass over plain CSS are *variables*, *nesting* and *m
|
||||
|
||||
- Use single quotes `'` for strings
|
||||
- Use this general nesting hierarchy when constructing your styles:
|
||||
|
||||
```scss
|
||||
// The base component class acts as the namespace, to avoid naming and style collisions
|
||||
.my-component {
|
||||
@@ -28,16 +29,17 @@ The main benefits of using Sass over plain CSS are *variables*, *nesting* and *m
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Note that with
|
||||
[Angular view encapsulation](https://angular.io/docs/ts/latest/guide/component-styles.html#!#view-encapsulation),
|
||||
the first "namespace" level of nesting is not necessary as Angular takes care of the scoping for avoid collisions.
|
||||
|
||||
> As a side note, we are aware of the [BEM naming approach](https://en.bem.info/tools/bem/bem-naming/), but we found
|
||||
it impractical for large projects. The nesting approach has drawbacks such as increased specificity, but it helps
|
||||
keeping everything nicely organized, and more importantly, *scoped*.
|
||||
|
||||
> it impractical for large projects. The nesting approach has drawbacks such as increased specificity, but it helps
|
||||
> keeping everything nicely organized, and more importantly, _scoped_.
|
||||
|
||||
Also keep in mind this general rules:
|
||||
|
||||
- Always use **class selectors**, never use ID selectors and avoid element selectors whenever possible
|
||||
- No more than **3 levels** of nesting
|
||||
- No more than **3 qualifiers**
|
||||
@@ -45,7 +47,9 @@ Also keep in mind this general rules:
|
||||
## Best practices
|
||||
|
||||
- Use object-oriented CSS (OOCSS):
|
||||
* Factorize common code in base class, and extend it, for example:
|
||||
|
||||
- Factorize common code in base class, and extend it, for example:
|
||||
|
||||
```scss
|
||||
// Base button class
|
||||
.btn { ... }
|
||||
@@ -56,31 +60,30 @@ Also keep in mind this general rules:
|
||||
// Size variation
|
||||
.btn-small { ... }
|
||||
```
|
||||
* Try to name class by semantic, not style nor function for better reusability:
|
||||
|
||||
- Try to name class by semantic, not style nor function for better reusability:
|
||||
Use `.btn-warning`, not `btn-orange` nor `btn-cancel`
|
||||
* Avoid undoing style, refactor using common base classes and extensions
|
||||
- Avoid undoing style, refactor using common base classes and extensions
|
||||
|
||||
- Keep your style scoped
|
||||
* Clearly separate **global** (think *framework*) and **components** style
|
||||
* Global style should only go in `src/theme/`, never in components
|
||||
* Avoid style interactions between components, if some style may need to be shared, refactor it as a framework
|
||||
- Clearly separate **global** (think _framework_) and **components** style
|
||||
- Global style should only go in `src/theme/`, never in components
|
||||
- Avoid style interactions between components, if some style may need to be shared, refactor it as a framework
|
||||
component in put it in your global theme.
|
||||
* Avoid using wider selectors than needed: always use classes if you can!
|
||||
|
||||
- Avoid using wider selectors than needed: always use classes if you can!
|
||||
- Avoid rules multiplication
|
||||
* The less CSS the better, factorize rules whenever it's possible
|
||||
* CSS is code, and like any code frequent refactoring is healthy
|
||||
|
||||
- The less CSS the better, factorize rules whenever it's possible
|
||||
- CSS is code, and like any code frequent refactoring is healthy
|
||||
- When ugly hacks cannot be avoided, create an explicit `src/hacks.scss` file and put it in:
|
||||
* These ugly hacks should only be **temporary**
|
||||
* Each hack should be documented with the author name, the problem and hack reason
|
||||
* Limit this file to a reasonable length (~100 lines) and refactor hacks with proper solutions when the limit is
|
||||
- These ugly hacks should only be **temporary**
|
||||
- Each hack should be documented with the author name, the problem and hack reason
|
||||
- Limit this file to a reasonable length (~100 lines) and refactor hacks with proper solutions when the limit is
|
||||
reached.
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- Never use the `!important` keyword. Ever.
|
||||
- Never use **inline** style in html, even *just for debugging* (because we **KNOW** it will end up in your commit)
|
||||
- Never use **inline** style in html, even _just for debugging_ (because we **KNOW** it will end up in your commit)
|
||||
|
||||
## Browser compatibility
|
||||
|
||||
|
||||
@@ -23,9 +23,9 @@ In addition, this project also follows the general [Angular style guide](https:/
|
||||
|
||||
- Within a file, type definitions should come first
|
||||
- Within a class, these priorities should be respected:
|
||||
* Properties comes before functions
|
||||
* Static symbols comes before instance symbols
|
||||
* Public symbols comes before private symbols
|
||||
- Properties comes before functions
|
||||
- Static symbols comes before instance symbols
|
||||
- Public symbols comes before private symbols
|
||||
|
||||
## Coding rules
|
||||
|
||||
@@ -41,9 +41,9 @@ In addition, this project also follows the general [Angular style guide](https:/
|
||||
- Use arrow functions over anonymous function expressions
|
||||
- Only surround arrow function parameters when necessary.
|
||||
For example, `(x) => x + x` is wrong but the following are correct:
|
||||
* `x => x + x`
|
||||
* `(x, y) => x + y`
|
||||
* `<T>(x: T, y: T) => x === y`
|
||||
- `x => x + x`
|
||||
- `(x, y) => x + y`
|
||||
- `<T>(x: T, y: T) => x === y`
|
||||
|
||||
## Definitions
|
||||
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Unit tests coding guide
|
||||
|
||||
The main objective of unit tests is to detect regressions and to help you design software components. A suite of
|
||||
*good* unit tests can be *immensely* valuable for your project and makes it easier to refactor and expand your code.
|
||||
But keep in mind that a suite of *bad* unit tests can also be *immensely* painful, and hurt your development by
|
||||
_good_ unit tests can be _immensely_ valuable for your project and makes it easier to refactor and expand your code.
|
||||
But keep in mind that a suite of _bad_ unit tests can also be _immensely_ painful, and hurt your development by
|
||||
inhibiting your ability to refactor or alter your code in any way.
|
||||
|
||||
## What to test?
|
||||
@@ -25,7 +25,7 @@ integration and interactions with other app components based on real use cases s
|
||||
- Test only one code unit at a time: if you cannot do this, it means you have an architecture problem in your app
|
||||
- Mock out all external dependencies and state: if there is too much to mock, it is often a sign that maybe you
|
||||
should split your tested module into several more independent modules
|
||||
- Clearly separate or identify these 3 stages of each unit test (the *3A*): *arrange*, *act* and *assert*
|
||||
- Clearly separate or identify these 3 stages of each unit test (the _3A_): _arrange_, _act_ and _assert_
|
||||
- When you fix a bug, add a test case for it to prevent regression
|
||||
|
||||
## Pitfalls
|
||||
|
||||
@@ -15,6 +15,7 @@ In Windows environments, add the `HTTP_PROXY` and `HTTPS_PROXY` system environme
|
||||
### Unix
|
||||
|
||||
Add these lines to your `~/.bash_profile` or `~/.profile`:
|
||||
|
||||
```sh
|
||||
export HTTP_PROXY="http://<username>:<password>@<proxy_server>:<proxy_port>"
|
||||
export HTTPS_PROXY="$HTTP_PROXY"
|
||||
@@ -44,6 +45,7 @@ export NO_PROXY="127.0.0.1, localhost, <your_local_server_ip_or_hostname>"
|
||||
### Npm
|
||||
|
||||
Run this command in your project directory:
|
||||
|
||||
```sh
|
||||
npm set strict-ssl false
|
||||
```
|
||||
|
||||
+16
-12
@@ -7,11 +7,13 @@ The internationalization of the application is managed by [ngx-translate](https:
|
||||
### In HTML templates
|
||||
|
||||
Use the `translate` directive on an HTML element to automatically translate its content:
|
||||
|
||||
```html
|
||||
<span translate>This text will be translated.</span>
|
||||
```
|
||||
|
||||
You can also use the `translate` pipe if needed:
|
||||
|
||||
```html
|
||||
<button title="{{'Add item' | translate}}">+</button>
|
||||
```
|
||||
@@ -23,7 +25,9 @@ If you need to translate strings in JavaScript code, import the `TranslateServic
|
||||
|
||||
```typescript
|
||||
let title;
|
||||
translateService.get('My page title').subscribe((res: string) => { title = res; });
|
||||
translateService.get('My page title').subscribe((res: string) => {
|
||||
title = res;
|
||||
});
|
||||
```
|
||||
|
||||
or `TranslateService` dependency and use the asynchronous
|
||||
@@ -46,16 +50,16 @@ Do no forget to edit the files in `src/environment` to add the supported languag
|
||||
These are the Language available now:
|
||||
|
||||
| Language | Code | File |
|
||||
|:----------:|:----:|:----------:|
|
||||
| Czech | cs | cs-CS.json |
|
||||
| German | de | de-DE.json |
|
||||
| English | en | en-US.json |
|
||||
| Spanish | es | es-MX.json |
|
||||
| French | fr | fr-FR.json |
|
||||
| Italian | it | it-IT.json |
|
||||
| Korean | ko | ko-KO.json |
|
||||
| :--------: | :--: | :--------: |
|
||||
| Czech | cs | cs-CS.json |
|
||||
| German | de | de-DE.json |
|
||||
| English | en | en-US.json |
|
||||
| Spanish | es | es-MX.json |
|
||||
| French | fr | fr-FR.json |
|
||||
| Italian | it | it-IT.json |
|
||||
| Korean | ko | ko-KO.json |
|
||||
| Lithuanian | li | li-LI.json |
|
||||
| Latvian | lv | lv-LV.json |
|
||||
| Nepali | ne | ne-NE.json |
|
||||
| Latvian | lv | lv-LV.json |
|
||||
| Nepali | ne | ne-NE.json |
|
||||
| Portuguese | pt | pt-PT.json |
|
||||
| Swahili | sw | sw-SW.json |
|
||||
| Swahili | sw | sw-SW.json |
|
||||
|
||||
+6
-7
@@ -2,7 +2,7 @@
|
||||
|
||||
To allow navigation without triggering a server request, Angular now use by default the
|
||||
[HTML5 pushState](https://developer.mozilla.org/en-US/docs/Web/API/History_API#Adding_and_modifying_history_entries)
|
||||
API enabling natural URL style (like `localhost:4200/home/`), in opposition to Angular 1 which used the *hashbang* hack
|
||||
API enabling natural URL style (like `localhost:4200/home/`), in opposition to Angular 1 which used the _hashbang_ hack
|
||||
routing style (like `localhost:4200/#/home/`).
|
||||
|
||||
This change has several consequences you should know of, be sure to read the
|
||||
@@ -13,8 +13,7 @@ In short:
|
||||
|
||||
- It is only supported on modern browsers (IE10+), a [polyfill](https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills#html5-history-api-pushstate-replacestate-popstate)
|
||||
is required for older browsers.
|
||||
|
||||
- You have the option to perform *server-side rendering* later if you need to increase your app perceived performance.
|
||||
- You have the option to perform _server-side rendering_ later if you need to increase your app perceived performance.
|
||||
|
||||
- You need to [configure URL rewriting](#server-configuration) on your server so that all routes serve your index file.
|
||||
|
||||
@@ -23,7 +22,7 @@ default HTML5 routing mode.
|
||||
|
||||
## Server configuration
|
||||
|
||||
To allow your angular application working properly as a *Single Page Application* (SPA) and allow bookmarking or
|
||||
To allow your angular application working properly as a _Single Page Application_ (SPA) and allow bookmarking or
|
||||
refreshing any page, you need some configuration on your server, otherwise you will be running into troubles.
|
||||
|
||||
> Note that during development, the live reload server already supports SPA mode.
|
||||
@@ -34,10 +33,10 @@ Here is an example on how to perform this on an [Express](http://expressjs.com)
|
||||
|
||||
```js
|
||||
// Put this in your `server.js` file, after your other rules (APIs, static files...)
|
||||
app.get('/*', function(req, res) {
|
||||
res.sendFile(__dirname + '/index.html')
|
||||
app.get('/*', function (req, res) {
|
||||
res.sendFile(__dirname + '/index.html');
|
||||
});
|
||||
```
|
||||
|
||||
For other servers like [Nginx](https://www.nginx.com/blog/creating-nginx-rewrite-rules/) or
|
||||
[Apache](http://httpd.apache.org/docs/2.0/misc/rewriteguide.html), you may look for how to perform *URL rewriting*.
|
||||
[Apache](http://httpd.apache.org/docs/2.0/misc/rewriteguide.html), you may look for how to perform _URL rewriting_.
|
||||
|
||||
+6
-1
@@ -1,21 +1,25 @@
|
||||
# Updating npm dependencies
|
||||
|
||||
- Check outdated packages
|
||||
|
||||
```sh
|
||||
npm outdated
|
||||
```
|
||||
|
||||
- Update local packages according to `package.json`
|
||||
|
||||
```sh
|
||||
npm update
|
||||
```
|
||||
|
||||
- Upgrade packages manually
|
||||
|
||||
```sh
|
||||
npm install --save[-dev] <package_name>@latest
|
||||
```
|
||||
|
||||
Alternatively, you can use [npm-check](https://github.com/dylang/npm-check) to perform an interactive upgrade:
|
||||
|
||||
```sh
|
||||
npm-check -u --skip-unused
|
||||
```
|
||||
@@ -28,13 +32,14 @@ reproducible dependency tree and avoid unwanted package updates.
|
||||
|
||||
If you use a previous npm version, it is recommended to use [npm shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) to
|
||||
lock down all your dependencies version:
|
||||
|
||||
```sh
|
||||
npm shrinkwrap --dev
|
||||
```
|
||||
|
||||
This will create a file `npm-shrinkwrap.json` alongside your `package.json` files.
|
||||
|
||||
> Do not forget to run shrinkwrap each time you manually update your dependencies!
|
||||
> Do not forget to run shrinkwrap each time you manually update your dependencies!
|
||||
|
||||
# Updating angular-cli
|
||||
|
||||
|
||||
Reference in New Issue
Block a user