|
| 1 | + |
| 2 | + |
1 | 3 | # Images Downloader |
2 | 4 |
|
3 | 5 | An interactive Command-Line Interface Build in NodeJS for downloading a single or multiple images to disk from URL. |
4 | 6 |
|
5 | 7 |
|
6 | | -<p align="center"> |
7 | | -<img src="screenshots/test.gif" > |
8 | | -</p> |
| 8 | +## Prerequisites |
| 9 | + |
| 10 | +To build and run this cli locally you will need a few things: |
| 11 | +- Install [Node.js](https://nodejs.org/en/) |
| 12 | +- Install [NPM](https://www.npmjs.com/) |
9 | 13 |
|
10 | 14 |
|
11 | 15 | # Install |
12 | 16 |
|
| 17 | +- From npm |
13 | 18 | ``` |
14 | 19 |
|
15 | 20 | yarn add global img-cli |
16 | 21 |
|
17 | 22 | ``` |
18 | 23 |
|
| 24 | +- From GPR |
| 25 | +``` |
| 26 | +
|
| 27 | +npm install @selmi-karim/img-cli -g |
| 28 | +``` |
| 29 | + |
19 | 30 | # Command Topics |
20 | 31 | ### img all |
21 | 32 |
|
@@ -56,6 +67,50 @@ EXAMPLES |
56 | 67 | |
57 | 68 | ``` |
58 | 69 |
|
| 70 | +## NPM scripts |
| 71 | + |
| 72 | + - `npm run release`: release new version |
| 73 | + - `npm run lint`: Lints code |
| 74 | + - `npm run lint:fix`: Lints auto-fix code |
| 75 | + - `npm run commit`: Commit using conventional commit style ([husky](https://github.com/typicode/husky) will tell you to use it if you haven't :wink:) |
| 76 | + |
| 77 | +## Git Hooks |
| 78 | + |
| 79 | +There is already set a `precommit` hook for formatting your code with Prettier :nail_care: |
| 80 | + |
| 81 | +By default, there are two disabled git hooks. They're set up when you run the `npm run semantic-release-prepare` script. They make sure: |
| 82 | + - You follow a [conventional commit message](https://github.com/conventional-changelog/conventional-changelog) |
| 83 | + |
| 84 | +This makes more sense in combination with [automatic releases](#automatic-releases) |
| 85 | + |
| 86 | + |
| 87 | +## Built With |
| 88 | + |
| 89 | +* [Github Actions](https://github.com/actions) - CI & CD |
| 90 | +* [npm](https://www.npmjs.com) - Dependency Management |
| 91 | +* [nodejs](https://nodejs.org/en/) |
| 92 | + |
| 93 | + |
| 94 | + |
| 95 | +## Versioning and Release |
| 96 | + |
| 97 | +### Semantic Versioning |
| 98 | + |
| 99 | +We follow the [**Semantic Versioning**](https://semver.org/#summary]) scheme. |
| 100 | +> set of rules and requirements that dictate how version numbers are assigned and incremented. These rules are based on but not necessarily limited to pre-existing widespread common practices in use in both closed and open-source software... Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next. |
| 101 | +
|
| 102 | +Reading the semantic versioning docs more than once will get you a solid understanding on how we version and tag our software releases. |
| 103 | + |
| 104 | +### Semantic Release |
| 105 | + |
| 106 | +We use **[semantic-release](https://github.com/semantic-release/semantic-release)** to manage and automate complex release workflows. |
| 107 | +>**semantic-release** automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package. |
| 108 | +This removes the immediate connection between human emotions and version numbers, strictly following the [Semantic Versioning](http://semver.org/) specification. |
| 109 | + |
| 110 | +As a SWE you will not be versioning nor releasing manually software, as everything is automated. But a solid insight on how we do things will make your vision and sense of understanding match your teammate's. |
| 111 | + |
| 112 | + |
| 113 | + |
59 | 114 | # Questions? |
60 | 115 |
|
61 | 116 | Feel free to contact <a href="http://www.karimation.com">me</a> or create an issue. |
|
0 commit comments