Skip to main content

Contributing to easy-dates

First off, thanks for taking the time to contribute! 🎉

The following is a set of guidelines for contributing to easy-dates. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Code of Conduct​

This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to hello@sandypockets.dev.

How Can I Contribute?​

Reporting Bugs​

This section guides you through submitting a bug report. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.

Before creating bug reports, please check this list as you might find out that you don't need to create one.

When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps resolve issues faster.

Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

Before Submitting A Bug Report​

  • Check if you can reproduce the problem in the latest version of easy-dates. The current version is
  • Check the existing open and closed issues, to be sure that the issue has not already been triaged or resolved.

How Do I Submit A (Good) Bug Report?​

Bugs are tracked as GitHub issues. Create an issue, and provide the following information by filling in the questions in the issue template.

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps which reproduce the problem in as many details as possible.
  • Provide specific examples to demonstrate the steps. Include links to files or GitHub projects, or copy/pasteable snippets, (or examples in StackBlitz or CodeSandbox), which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
  • Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
  • Explain which behavior you expected to see instead and why.
  • Include screenshots and animated GIFs which show you following the described steps and clearly demonstrate the problem.

Suggesting Enhancements​

When you are creating an enhancement suggestion, please include as many details as possible, including the steps that you imagine you would take if the feature you're requesting existed.

Before Submitting An Enhancement Suggestion​

  • Perform a cursory search to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one. Enhancement suggestions are tracked as GitHub issues. Create an issue in the repository and provide the following information:
  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Provide a step-by-step description of the suggested enhancement in as many details as possible.
  • Provide specific examples to demonstrate the steps. Include copy/pasteable snippets which you use in those examples, as Markdown code blocks.
  • Describe the current behavior and explain which behavior you expected to see instead and why.

Pull Requests​

The maintainers must be satisfied prior to having your pull request reviewed, and the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.

Styleguides​

Git Commit Messages​

  • Use the present tense ("Add feature" not "Added feature")
  • Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  • Limit the first line to 72 characters or less

JavaScript Styleguide​

All JavaScript code is linted with Prettier.

  • Prefer the object spread operator ({...anotherObj}) to Object.assign()
  • Inline exports with expressions whenever possible

Automating the development process​

If you're writing new functions for the library, then you can use a the createNewFunctionFiles script to generate a new function file and test file. To run the script, run the following command, replacing myNewFunctionName with the actual name of the function you're creating:

yarn new myNewFunctionName

This will generate a new directory with a new function file and test file.

src/myNewFunctionName/myNewFunctionName.js
src/myNewFunctionName/myNewFunctionName.test.js

It will also generate an export statement in the src/index.js file, and create a new documentation entry in the docs/myNewFunctionName.md file.

Testing your new function​

When your function code and tests are written, run yarn test. This will lint your code, run the build script, then run your tests. If you have any errors, you can fix them and re-run the tests by once again running yarn test. Once all test are passing, submit your pull request.