String 2.0.1

Author: Awilum

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,31 @@
+# Code of Conduct
+
+Like the technical community as a whole, the Faker Javascript team and community is made up of a mixture of professionals and volunteers from all over the world, working on every aspect of the mission - including mentorship, teaching, and connecting people.
+
+Diversity is one of our strengths. With that, challenges will arise that can lead to communication issues and unhappiness. To that end, we have a few ground rules that we ask people to adhere to. This code applies equally to founders, mentors and those seeking help and guidance.
+
+This isn’t an exhaustive list of things that you can’t do. Rather, take it in the spirit in which it’s intended - a guide to make it easier to enrich all of us and the technical communities in which we participate.
+
+This code of conduct applies to all spaces used by the Faker Javascript community for communication. This includes Discord, GitHub, Twitter, Facebook, meetups, conferences, and any other relevant forums. Violations of this code outside of any spaces managed by the Faker Javascript team will still affect a person’s ability to participate within them.
+
+If you believe someone is violating the code of conduct, we ask that you report it by contacting us from [support@flextype.org](mailto:[email protected]). We take all reports seriously, and your identity will remain confidential.
+
+- **Be friendly and patient.**
+- **Be welcoming.** We strive to be a community that welcomes and supports people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, colour, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability.
+- **Be considerate.** Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and you should take those consequences into account when making decisions. Remember that we’re a world-wide community, so you might not be communicating in someone else’s primary language.
+- **Be respectful.** Not all of us will agree all the time, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. Members of the Faker Javascript community should be respectful when dealing with other members as well as with people outside the Faker Javascript community.
+- **Be careful in the words that you choose.** We are a community of professionals, and we conduct ourselves professionally. Be kind to others. Do not insult or put down other participants. Harassment and other exclusionary behavior aren’t acceptable. This includes, but is not limited to:
+
+  - Violent threats or language directed against another person.
+  - Discriminatory jokes and language.
+  - Exclusionary gendered language (guys, gentlemen, bros, etc).
+  - Posting sexually explicit or violent material.
+  - Posting (or threatening to post) other people’s personally identifying information ("doxing").
+  - Personal insults, especially those using racist or sexist terms.
+  - Unwelcome sexual attention.
+  - Advocating for, or encouraging, any of the above behavior.
+  - Repeated harassment of others. In general, if someone asks you to stop, then stop.
+
+- **When we disagree, try to understand why.** Disagreements, both social and technical, happen all the time and Faker Javascript is no exception. It is important that we resolve disagreements and differing views constructively. Remember that we’re different. The strength of Faker Javascript comes from its varied community, people from a wide range of backgrounds. Different people have different perspectives on issues. Being unable to understand why someone holds a viewpoint doesn’t mean that they’re wrong. Don’t forget that it is human to err and blaming each other doesn’t get us anywhere. Instead, focus on helping to resolve issues and learning from mistakes.
+
+*Credits for the sources and inspiration of this code of conduct go to the [Speak Up! project.](http://web.archive.org/web/20141109123859/http://speakup.io/coc.html)*

.github/COMMIT_CONVENTION.md

@@ -0,0 +1,58 @@
+# Git Commit Message Convention
+We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history.
+
+## Commit Message Format
+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>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+The **header** is mandatory and the **scope** of the header is optional.
+
+Any line of the commit message cannot be longer 72 characters! This allows the message to be easier
+to read on GitHub as well as in various git tools.
+
+The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
+
+Samples: (even more [samples](https://github.com/faker-javascript/string/commits/master))
+
+### 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
+The type of the made changes. Should be one of:
+* **feat** - some feature development
+* **fix** - bug fix
+* **docs** - changes in documentation
+* **style** - changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+* **perf**: A code change that improves performance
+* **refactor** - changes those do not fix a bug or implement a feature. Simple refactoring
+* **test** - adding missing tests or correcting existing tests
+* **chore** - any other changes, not affecting code
+* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+
+### Scope
+The scope could be anything specifying the place of the commit change. For example core, docs, 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.

.github/FUNDING.yml

@@ -0,0 +1,4 @@
+# These are supported funding model platforms
+
+patreon: awilum
+custom: ['https://paypal.me/awilum', 'https://qiwi.com/p/79805359141']

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,27 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+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.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

CHANGELOG.md

@@ -1,3 +1,7 @@
+<a name="2.0.1"></a>
+# [2.0.1](https://github.com/faker-javascript/string) (2022-01-10)
+* GitHub docs updates.
+
 <a name="2.0.0"></a>
 # [2.0.0](https://github.com/faker-javascript/string) (2022-01-09)
 

README.md

@@ -20,10 +20,10 @@ import string from '@fakerjs/string';
 string();
 //=> 3Kekravwvb78vP9CQPP1vaRCgi4dZETOktxzf8pF5gufFqh8mOICMqjRP4y8UxoI
 
-string(10);
+string({length: 10});
 //=> FxvqHNFNUu
 
-string(10, '#@$%&+=');
+string({length: 10, keyspace: '#@$%&+='});
 //=> $+#%#&$$=@
 ```
 

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fakerjs/string",
-  "version": "2.0.0",
+  "version": "2.0.1",
   "description": "String package provides functionality to generate a fake string value.",
   "license": "MIT",
   "repository": "faker-javascript/string",

test.js

@@ -1,7 +1,6 @@
 import string from './index.js';
 import test from 'ava';
 
-//console.log(string({length: 10}));
 test('string return type to be string', t => {
 	t.is(typeof string(), 'string');
 });