Skip to content

Commit 8a74630

Browse files
committed
feat: add gpr
1 parent c46a163 commit 8a74630

1 file changed

Lines changed: 58 additions & 3 deletions

File tree

README.md

Lines changed: 58 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,21 +1,32 @@
1+
![release](https://github.com/selmi-karim/img-cli/workflows/release/badge.svg)
2+
13
# Images Downloader
24

35
An interactive Command-Line Interface Build in NodeJS for downloading a single or multiple images to disk from URL.
46

57

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/)
913

1014

1115
# Install
1216

17+
- From npm
1318
```
1419
1520
yarn add global img-cli
1621
1722
```
1823

24+
- From GPR
25+
```
26+
27+
npm install @selmi-karim/img-cli -g
28+
```
29+
1930
# Command Topics
2031
### img all
2132

@@ -56,6 +67,50 @@ EXAMPLES
5667
5768
```
5869

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+
59114
# Questions?
60115

61116
Feel free to contact <a href="http://www.karimation.com">me</a> or create an issue.

0 commit comments

Comments
 (0)