GitHub Community Checklist | Building an NPM Package with TypeScript
Recommended community standards will help you maintain your package. To see the standard files that GitHub recommends you to add to your project, you can go to insights and community. Here you see a checklist of items to go through.
/ github-community-checklist-building-a-npm-...
First, you have the description, it is self explanatory and can be the same as the description you will add to your package.json. You should add the description to the home page of your repository.
README
README is the file that will contain information about getting started with your project, installation, links to the contributing guide, and other resources related to the project.
Code of Conduct
There are two “code of conducts” proposed by GitHub when you add the file on the website. The Contributor Covenant Code of Conduct is a good and simple one that I would recommend. It establishes the expectation of people acting like decent human beings.
If you wish to have something more custom, you can start with the Citizen Code of Conduct as a base. It is more detailed and will give you some ideas on what sections to add to your own.
Contributing guide
The contributing guide contains information for your contributors about what you expect from them, how to set up the project to be able to do a pull request. It will come in handy if someone wants to fix a bug, or develop one of the feature requests in the issues.
License
The reason why a license is important for any project is because it is essentially a legal document that indicates the permissions that you give to other developers, companies on your project. So you will have licenses that will allow developers to use the project commercially, for profit, or will restrain the usage for non profit. Depending on what license you choose, some companies might unauthorised their developers to use your project.
Issue templates/forms
Templates are quite important if you want to make your project public. One of the most challenging part of a project is not the code itself, but handling the feedback, issues and pull requests.
When there is an issue with your project, the main difficulty is to get the correct information from the requester so that you can reproduce the issue, and debug it more easily. With a template, you can force, in some way, the issuer to provide this information. You can create multiple issues templates, for different type of issues.
An issue form is written in YAML, you can create fields that can be required, forcing the person writing the issue to complete the information. Fields will have a type (textarea, checkboxes), a description, a label, verification (if required or not), options (for checkboxes). The form is quite flexible.
Pull request template
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.
What types of changes does your code introduce? Bug fixes, new feature, breaking change (will impact semantic versioning).
Checklist of steps that needs to be done. Lint, Format, add tests. This is to ensure the requester has done the work.