chore: First init

Author: CodeDredd

.editorconfig

@@ -0,0 +1,12 @@
+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/CODE_OF_CONDUCT.md

@@ -0,0 +1,13 @@
+# Contributor Code of Conduct
+
+As contributors and maintainers of this project, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.
+
+We are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, age, or religion.
+
+Examples of unacceptable behavior by participants include the use of sexual language or imagery, derogatory comments or personal attacks, trolling, public or private harassment, insults, or other unprofessional conduct.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct. Project maintainers who do not follow the Code of Conduct may be removed from the project team.
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
+
+This Code of Conduct is adapted from the [Contributor Covenant](http://contributor-covenant.org), version 1.0.0, available at [http://contributor-covenant.org/version/1/0/0/](http://contributor-covenant.org/version/1/0/0/)

.github/CONTRIBUTING.md

@@ -0,0 +1,26 @@
+# Contributing
+
+Contributions are welcome and will be fully credited!
+
+We accept contributions via Pull Requests on [Github](https://github.com/{{ githubAccount }}/{{ name }}).
+
+## Pull Requests
+
+Here are some guidelines to make the process smoother:
+
+- **Add a test** - New features and bugfixes need tests. If you find it difficult to test, please tell us in the pull request and we will try to help you!
+- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date.
+- **Run `npm test` locally** - This will allow you to go faster
+- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
+- **Send coherent history** - Make sure your commits message means something
+- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option.
+
+## Creating issues
+
+### Bug reports
+
+Always try to provide as much information as possible. If you are reporting a bug, try to provide a repro on jsfiddle.net (or anything else) or a stacktrace at the very least. This will help us check the problem quicker.
+
+### Feature requests
+
+Lay out the reasoning behind it and propose an API for it. Ideally, you should have a practical example to prove the utility of the feature you're requesting.

.github/FUNDING.yml

@@ -0,0 +1 @@
+github: codedredd

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,9 @@
+<!--
+IMPORTANT: Please provide as much information as possible:
+
+    - Reporting a bug: Provide a reproduction using this template: https://github.com/piniajs/bug-report
+    If no reproduction is provided, your issue will be closed or moved to a discussion.
+
+    - Feature request: lay out the reasoning behind it and propose an API for it
+
+-->

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,31 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+---
+
+### Reproduction
+
+If possible, provide a boiled down editable reproduction using a service like JSFiddle, Codepen, CodeSandbox, or a GitHub repository based on this template: https://github.com/piniajs/bug-report. A failing unit test is even better! Otherwise provide as much information as possible to reproduce the problem. You can find examples of different environments at https://github.com/piniajs?q=example&type=source and use them as a bug reproduction.
+If no reproduction is provided and the information is not enough to reproduce the problem, we won't be able to give it a look **and the issue will be converted into a question and moved to discussions**.
+
+### Steps to reproduce the behavior
+
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+### Expected behavior
+
+A clear and concise description of what you expected to happen.
+
+### Actual behavior
+
+A clear and concise description of what actually happens.
+
+### Additional information
+
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,11 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Question
+    url: https://github.com/vuejs/pinia/discussions/new?category=Q-A
+    about: Ask a question or discuss about Pinia
+  - name: Ideas
+    url: https://github.com/vuejs/pinia/discussions/new?category=Ideas
+    about: Start a discussion to improve Pinia
+  - name: GitHub Sponsors
+    url: https://github.com/sponsors/posva
+    about: Like this project? Please consider supporting the author.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: feature request
+assignees: ''
+
+---
+
+### What problem is this solving
+
+A clear and concise description of what the problem is. Ex. when using the function X we cannot do Y.
+
+### Proposed solution
+
+A clear and concise description of what you want to happen with an API proposal when applicable
+
+### Describe alternatives you've considered
+
+A clear and concise description of any alternative solutions or features you've considered.

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,4 @@
+<!--
+Please make sure to include a test! If this is closing an
+existing issue, reference that issue as well.
+-->

.github/commit-convention.md

@@ -0,0 +1,91 @@
+## Git Commit Message Convention
+
+> This is adapted from [Angular's commit convention](https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog-angular).
+
+#### TL;DR:
+
+Messages must be matched by the following regex:
+
+```text
+/^(revert: )?(feat|fix|docs|dx|style|refactor|perf|test|workflow|build|ci|chore|types|wip)(\(.+\))?: .{1,50}/
+```
+
+#### Examples
+
+Appears under "Features" header, `link` subheader:
+
+```
+feat(link): add `force` option
+```
+
+Appears under "Bug Fixes" header, `view` subheader, with a link to issue #28:
+
+```
+fix(view): handle keep-alive with aborted navigations
+
+close #28
+```
+
+Appears under "Performance Improvements" header, and under "Breaking Changes" with the breaking change explanation:
+
+```
+perf: improve guard extraction
+
+BREAKING CHANGE: The 'beforeRouteEnter' option has been removed.
+```
+
+The following commit and commit `667ecc1` do not appear in the changelog if they are under the same release. If not, the revert commit appears under the "Reverts" header.
+
+```
+revert: feat(compiler): add 'comments' option
+
+This reverts commit 667ecc1654a317a13331b17617d973392f415f02.
+```
+
+### Full Message Format
+
+A commit message consists of a **header**, **body** and **footer**. The header has a **type**, **scope** and **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+The **header** is mandatory and the **scope** of the header is optional.
+
+### 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.
+
+### Type
+
+If the prefix is `feat`, `fix` or `perf`, it will appear in the changelog. However, if there is any [BREAKING CHANGE](#footer), the commit will always appear in the changelog.
+
+Other prefixes are up to your discretion. Suggested prefixes are `docs`, `chore`, `style`, `refactor`, and `test` for non-changelog related tasks.
+
+### Scope
+
+The scope could be anything specifying the place of the commit change. For example `core`, `compiler`, `ssr`, `v-model`, `transition` etc...
+
+### Subject
+
+The subject contains a succinct 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
+
+### 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.