feat(convention): add project templates and commit conventions

.editorconfig

@@ -0,0 +1,13 @@
+# editorconfig.org
+root = true
+
+[*]
+indent_size = 2
+indent_style = space
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.md]
+trim_trailing_whitespace = false

.github/COMMIT_CONVENTION.md

@@ -0,0 +1,67 @@
+## Git Commit Message Convention
+
+Using conventional commit messages, we can automate the process of generating the CHANGELOG file. All commits messages will automatically be validated against the following regex.
+
+``` js
+/^(revert: )?(feat|fix|docs|style|refactor|perf|test|workflow|ci|chore|types|build|improvement)((.+))?: .{1,50}/
+```
+
+## Commit Message Format
+A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**:
+
+> The **scope** is optional
+
+```
+feat(router): add support for prefix
+
+Prefix makes it easier to append a path to a group of routes
+```
+
+1. `feat` is type.
+2. `router` is scope and is optional
+3. `add support for prefix` is the subject
+4. The **body** is followed by a blank line.
+5. The optional **footer** can be added after the body, followed by a blank line.
+
+## Types
+Only one type can be used at a time and only following types are allowed.
+
+- feat
+- fix
+- docs
+- style
+- refactor
+- perf
+- test
+- workflow
+- ci
+- chore
+- types
+- build
+
+If a type is `feat` or `fix`, then the commit will appear in the CHANGELOG.md file. However if there is any BREAKING CHANGE, the commit will always appear in the changelog.
+
+### 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 SHA of the commit being reverted.
+
+## Scope
+The scope could be anything specifying place of the commit change. For example: `router`, `view`, `querybuilder`, `database`, `model` and so on.
+
+## Subject
+The subject contains succinct description of the change:
+
+- use the imperative, present tense: "change" not "changed" nor "changes".
+- don't capitalize 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.

.github/FUNDING.yml

@@ -0,0 +1 @@
+open_collective: secjs

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,21 @@
+<!-- CLICK "Preview" FOR INSTRUCTIONS IN A MORE READABLE FORMAT -->
+
+## Prerequisites
+
+- Ensure the issue isn't already reported.
+- Ensure you are reporting the bug in the correct repository.
+
+*Delete the above section and the instructions in the sections below before submitting*
+
+## Description
+
+If this is a feature request, explain why it should be added. Specific use-cases and problems that it solve are best.
+
+For bug reports, please provide as much *relevant* info as possible.
+
+## Package version
+<!-- YOUR ANSWER -->
+
+## Error Message & Stack Trace
+
+## Relevant Information

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,28 @@
+<!-- CLICK "Preview" FOR INSTRUCTIONS IN A MORE READABLE FORMAT -->
+
+## Proposed changes
+
+Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request. If it fixes a bug or resolves a feature request, be sure to link to that issue.
+
+## Types of changes
+
+What types of changes does your code introduce?
+
+_Put an `x` in the boxes that apply_
+
+- [ ] Bugfix (non-breaking change which fixes an issue)
+- [ ] New feature (non-breaking change which adds functionality)
+- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
+
+## Checklist
+
+_Put an `x` in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code._
+
+- [ ] I have read the [CONTRIBUTING](https://github.com/SecJS/Logger/blob/master/CONTRIBUTING.md) documentation
+- [ ] Lint and unit tests pass locally with my changes
+- [ ] I have added tests that prove my fix is effective or that my feature works.
+- [ ] I have added necessary documentation (if appropriate)
+
+## Further comments
+
+If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

.gitignore

@@ -1,6 +1,5 @@
-
 node_modules/
-dist/
+
 # Logs
 logs
 *.log
@@ -81,7 +80,6 @@ out
 
 # Nuxt.js build / generate output
 .nuxt
-dist
 
 # Gatsby files
 .cache/
@@ -123,7 +121,8 @@ dist
 .env.testing
 .env.production
 
-# Build archives
+# Build files
 *.js
 *.d.ts
+dist
 build

CONTRIBUTING.md

@@ -0,0 +1,48 @@
+# Contributing
+
+SecJS is a community driven project. You are free to contribute in any of the following ways.
+
+- [Coding style](coding-style)
+- [Fix bugs by creating PR's](fix-bugs-by-creating-prs)
+- [Share an RFC for new features or big changes](share-an-rfc-for-new-features-or-big-changes)
+- [Report security issues](report-security-issues)
+- [Be a part of the community](be-a-part-of-community)
+
+## Coding style
+
+Majority of SecJS core packages are written in Typescript. Having a brief knowledge of Typescript is required to contribute to the core.
+
+## Fix bugs by creating PR's
+
+We appreciate every time you report a bug in the packages. However, taking time to submit a PR can help us in fixing bugs quickly and ensure a healthy and stable eco-system.
+
+Go through the following points, before creating a new PR.
+
+1. Create an issue discussing the bug or short-coming in the package.
+2. Once approved, go ahead and fork the repository.
+3. Make sure to start from the `develop`, since this is the upto date branch.
+4. Make sure to keep commits small and relevant.
+5. We follow [conventional-commits](https://github.com/conventional-changelog/conventional-changelog) to structure our commit messages. Instead of running `git commit -m "message"`, you must run only `git commit`, which will show you prompts to create a valid commit message.
+6. Once done with all the changes, create a PR against the `develop` branch.
+
+## Share an RFC for new features or big changes
+
+Sharing PR's for small changes works great. However, when contributing big features to the package, it is required to go through the RFC process.
+
+### What is an RFC?
+
+RFC stands for **Request for Commits**, a standard process followed by many other frameworks including [Ember](https://github.com/emberjs/rfcs), [yarn](https://github.com/yarnpkg/rfcs) and [rust](https://github.com/rust-lang/rfcs).
+
+In brief, RFC process allows you to talk about the changes with everyone in the community and get a view of the core team before dedicating your time to work on the feature.
+
+The RFC proposals are created as issues on [SecJS/Rfcs](https://github.com/SecJS/Rfcs) repository. Make sure to read the README to learn about the process in depth.
+
+## Report security issues
+
+All the security issues, must be reported via [email](mailto:lenon@secjs.com.br) and not using any of the public channels.
+
+## Be a part of community
+
+We welcome you to participate in the [forum](https://forum.secjs.com.br/) and the SecJS [discord server](https://discord.me/secjs). You are free to ask your questions and share your work or contributions made to SecJS eco-system.
+
+We follow a strict [Code of Conduct](https://secjs.com.br/community-guidelines) to make sure everyone is respectful to each other.

README.md

@@ -5,12 +5,18 @@
 [![GitHub followers](https://img.shields.io/github/followers/jlenon7.svg?style=social&label=Follow&maxAge=2592000)](https://github.com/jlenon7?tab=followers)
 [![GitHub stars](https://img.shields.io/github/stars/secjs/logger.svg?style=social&label=Star&maxAge=2592000)](https://github.com/secjs/logger/stargazers/)
 
+<p>
+    <a href="https://www.buymeacoffee.com/secjs" target="_blank"><img src="https://www.buymeacoffee.com/assets/img/custom_images/orange_img.png" alt="Buy Me A Coffee" style="height: 41px !important;width: 174px !important;box-shadow: 0px 3px 2px 0px rgba(190, 190, 190, 0.5) !important;-webkit-box-shadow: 0px 3px 2px 0px rgba(190, 190, 190, 0.5) !important;" ></a>
+</p>
+
 <p>
   <img alt="GitHub language count" src="https://img.shields.io/github/languages/count/secjs/logger?style=for-the-badge&logo=appveyor">
 
   <img alt="Repository size" src="https://img.shields.io/github/repo-size/secjs/logger?style=for-the-badge&logo=appveyor">
 
   <img alt="License" src="https://img.shields.io/badge/license-MIT-brightgreen?style=for-the-badge&logo=appveyor">
+
+  <img alt="Commitizen" src="https://img.shields.io/badge/commitizen-friendly-brightgreen?style=for-the-badge&logo=appveyor">
 </p>
 
 The intention behind this repository is to always maintain a `Logger` package to any NodeJS project.
@@ -125,4 +131,6 @@ const s3Logger = new Logger('S3LoggerService', s3LogMapper)
 
 ---
 
+## License
+
 Made with 🖤 by [jlenon7](https://github.com/jlenon7) :wave: