Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/wessberg/sandhog

A virtual Open Source project maintainer
https://github.com/wessberg/sandhog

backers codegen codeofconduct contributing maintainers opensource project readme scaffold

Last synced: 9 days ago
JSON representation

A virtual Open Source project maintainer

Host: GitHub
URL: https://github.com/wessberg/sandhog
Owner: wessberg
License: mit
Created: 2018-06-30T13:21:10.000Z (over 6 years ago)
Default Branch: master
Last Pushed: 2024-10-17T21:10:23.000Z (19 days ago)
Last Synced: 2024-10-20T07:59:07.555Z (16 days ago)
Topics: backers, codegen, codeofconduct, contributing, maintainers, opensource, project, readme, scaffold
Language: TypeScript
Size: 2 MB
Stars: 15
Watchers: 3
Forks: 1
Open Issues: 4
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- Contributing: CONTRIBUTING.md
- Funding: .github/FUNDING.yml
- License: LICENSE.md
- Code of conduct: CODE_OF_CONDUCT.md

Awesome Lists containing this project

README

> A virtual Open Source project maintainer

Dependencies

## Description

Sandhog is a tool that makes it easy for you to have a welcoming, professional-looking Github repository.
It helps you generate and continuously maintain your `README.md`, `LICENSE.md`, `CONTRIBUTING.md`, `FUNDING.yml`, and `CODE_OF_CONDUCT.md` files by looking at the files inside your repository.
This README is generated by Sandhog.

### Features

Sandhog works out of the box without any configuration. Some highlights include:

- Generation of relevant badges for your README
- Generating of maintainer tables, including avatars, social links, and contact details
- Generation of Patreon and Open Collective backer/sponsor images that doesn't require any maintenance
- Generation of `LICENSE.md` files for a large variety of popular licenses.
- Generation of `CODE_OF_CONDUCT.md` files
- Generation of `CONTRIBUTING.md` files.
- Generation of `FUNDING.yml` files

## Backers

### Patreon

## Table of Contents

- [Description](#description)
- [Features](#features)
- [Backers](#backers)
- [Patreon](#patreon)
- [Table of Contents](#table-of-contents)
- [Install](#install)
- [npm](#npm)
- [Yarn](#yarn)
- [pnpm](#pnpm)
- [Run once with npx](#run-once-with-npx)
- [Engine](#engine)
- [Usage](#usage)
- [Configuration](#configuration)
- [Configuration options](#configuration-options)
- [Additional metadata for `package.json` fields](#additional-metadata-for-packagejson-fields)
- [CLI](#cli)
- [The `readme`-command](#the-readme-command)
- [The `license`-command](#the-license-command)
- [The `funding`-command](#the-funding-command)
- [The `contributing`-command](#the-contributing-command)
- [The `coc`-command (Code Of Conduct)](#the-coc-command-code-of-conduct)
- [The `all`-command](#the-all-command)
- [Readme structure](#readme-structure)
- [Readme sections](#readme-sections)
- [`toc` (Table of Contents)](#toc-table-of-contents)
- [`logo`](#logo)
- [`badges`](#badges)
- [`description_short`](#description_short)
- [`description_long`](#description_long)
- [`features`](#features)
- [`feature_image`](#feature_image)
- [`install`](#install)
- [`usage`](#usage)
- [`contributing`](#contributing)
- [`maintainers`](#maintainers)
- [`faq`](#faq)
- [`backers`](#backers)
- [`license`](#license)
- [Contributing](#contributing)
- [FAQ](#faq)
- [Do you support custom templates?](#do-you-support-custom-templates)
- [How do you determine the Code Style of the project?](#how-do-you-determine-the-code-style-of-the-project)
- [License](#license)

## Install

### npm

```
$ npm install sandhog --save-dev
```

### Yarn

```
$ yarn add sandhog --dev
```

### pnpm

```
$ pnpm add sandhog --save-dev
```

### Run once with npx

```
$ npx sandhog
```

## Engine

Sandhog requires Node.js v14.19.0 or newer to work correctly.

## Usage

### Configuration

Sandhog is highly configurable. You can provide a configuration in a variety of ways:

- As a `sandhog` property inside your `package.json` file.
- As a `sandhog.config.js` file within your repository root
- As a `sandhog.config.cjs` file within your repository root
- As a `sandhog.config.mjs` file within your repository root
- As a `sandhog.config.json` file within your repository root
- As a `sandhog.config.json5` file within your repository root
- As a `sandhog.config.yaml` file within your repository root
- As a `sandhog.config.yml` file within your repository root
- As a `.sandhogrc` (JSON-formatted) file within your repository root

#### Configuration options

```typescript
interface SandhogOptions {
// If true, the install directions inside generated READMEs will suggest installing this package as a development dependency.
isDevelopmentPackage: boolean;
// If provided, a logo image will be placed in the top of generated or updated README files
logo: {
// An URL to the logo.
url: string;
// The height of the logo in pixels
height: number;
};

// If provided, a feature image will be placed within generated or updated README files
featureImage: {
// An URL to the feature image.
url: string;
// The height of the feature image in pixels
height: number;
};
// If Patreon, Open Collective, and/or other donation options is given, badges and backer/sponsor shields will be generated and added to generated or updated README files.
donate: {
patreon: {
userId: string;
};
openCollective: {
project: string;
};
other: {
fundingUrl: string;
donors: [
{
name: string;
url: string;
imageUrl: string;
twitter: string;
}
];
};
};
readme: {
badges: {
// The given iterable of SectionKinds will never be added to generated or updated READMEs
// Can be any of the following: 'toc', 'logo', 'badges', 'description_short', 'description_long', 'features', 'feature_image', 'usage', 'install', 'contributing', 'maintainers', 'faq', 'backers', and 'license'
exclude: Iterable<
| "toc"
| "logo"
| "badges"
| "description_short"
| "description_long"
| "features"
| "feature_image"
| "usage"
| "install"
| "contributing"
| "maintainers"
| "faq"
| "backers"
| "license"
>;
};
sections: {
// The given iterable of BadgeKinds will never be added to generated or updated READMEs.
// Can be any of the following: 'downloads', 'dependencies', 'npm', 'contributors', 'license', 'patreon', 'open_collective_donate', 'open_collective_backers', 'open_collective_sponsors', and 'code_style'
exclude: Iterable<
| "downloads"
| "dependencies"
| "npm"
| "contributors"
| "license"
| "patreon"
| "open_collective_donate"
| "open_collective_backers"
| "open_collective_sponsors"
| "code_style"
>;
};
};
// By default, Sandhog will try to locate a Prettier config within the project. You can also just provide it or override the Prettier options here
prettier: PrettierOptions;
}
```

#### Additional metadata for `package.json` fields

Beyond the Sandhog configuration, Sandhog will look for metadata inside your `package.json` and use it to further enhance the files that can be
produced by Sandhog. For example, the `author` and/or `contributors` properties of your `package.json` can include additional keys such as the individual contributors
`imageUrl`, `twitter` handle, and `github` username.

For example:

```json5
// Inside package.json
{
contributors: [
{
name: "John Done",
email: "[email protected]",
url: "https://john.doe",

// The following three fields are enhancements
imageUrl: "https://john.doe/avatar.png",
role: "Lead Developer",
twitter: "JohnDoe",
github: "johndoe"
}
]
}
```

As seen in the code example above, contributors can be extended with the following optional properties:

| Property | Description |
| ---------- | ------------------------------------------------------------------------------------------ |
| `imageUrl` | An avatar that should be displayed above the rest of the information about the contributor |
| `role` | The role of the contributor within the project. |
| `twitter` | The Twitter handle for the contributor |
| `github` | The Github username for the contributor |

### CLI

```
$ sandhog --help

Usage: sandhog [options] [command]

Options:
-h, --help output usage information

Commands:
coc [options] Generates a CODE_OF_CONDUCT.md file
funding [options] Generates a FUNDING.yml file
contributing [options] Generates a CONTRIBUTING.md file
license [options] Generates a LICENSE.md file
readme [options] Generates a README.md file
all [options] Generates all of the files Sandhog supports in one command
```

#### The `readme`-command

```
$ sandhog readme --help
Usage: readme [options]

Generates a README.md file

Options:
-c, --config [arg] An (optional) path to the sandhog config to use
-d, --debug [arg] Whether to print debug information
-v, --verbose [arg] Whether to print verbose information
-s, --silent [arg] Whether to not print anything
-y, --yes [arg] Whether or not to auto-select 'yes' for all prompts
--section.exclude [arg] The comma-separated sections to exclude from the generated README.md
--badge.exclude [arg] The comma-separated badges to exclude from the generated README.md
-h, --help output usage information
```

The `readme` command will generate or update a `README.md` file. This README is generated via this command.
The sections of the README will vary depending on your configuration as well as the state of your repository.

If a `README.md` file already exists within the repository, you will be prompted for permission to overwrite it if it has changed,
unless the `--yes` option is given (see above).

#### The `license`-command

```
$ sandhog license --help
Usage: license [options]

Generates a LICENSE.md file

Options:
-c, --config [arg] An (optional) path to the sandhog config to use
-d, --debug [arg] Whether to print debug information
-v, --verbose [arg] Whether to print verbose information
-s, --silent [arg] Whether to not print anything
-y, --yes [arg] Whether or not to auto-select 'yes' for all prompts
-l, --license [arg] Override the license to use generate
-h, --help output usage information
```

The `license` command will generate or update a `LICENSE.md` file. See [this file](./LICENSE.md) for an example output.
It will attempt to find the license for the project within the `package.json` file or by parsing the existing
`LICENSE.md` file (if it exists) to try to determine a license.

You can override the discovery algorithm by explicitly providing a license via the `--license` flag (see above).

If a `LICENSE.md` file already exists within the repository, you will be prompted for permission to overwrite it
if it has changed, unless the `--yes` option is given (see above).

#### The `funding`-command

```
$ sandhog funding --help
Usage: funding [options]

Generates a FUNDING.yml file

The `funding` command will generate or update a `FUNDING.yml` file inside the `.github` subdirectory.
The file will follow the form as described in the [Github Sponsor guide](https://help.github.com/en/articles/displaying-a-sponsor-button-in-your-repository).

It will take the Patreon and Open Collective information if given in the [Sandhog config](#configuration), as well as parse the `package.json` for the author and/or contributors and add them to the Github Sponsors section if
a `github` username can be found. [See this section](#additional-metadata-for-packagejson-fields) for more details on the metadata that can be provided for authors and contributors.

If a `FUNDING.yml` file already exists within the `.github` subdirectory in the repository, you will be prompted for permission to overwrite it
if it has changed, unless the `--yes` option is given (see above).

#### The `contributing`-command

```
$ sandhog contributing --help
Usage: contributing [options]

Generates a CONTRIBUTING.md file

The `contributing` command will generate or update a `CONTRIBUTING.md` file in a friendly language. See [this file](./CONTRIBUTING.md) for an example output.
It will parse the package.json for the author and/or contributors and use them within the generated file if possible.

If a `CONTRIBUTING.md` file already exists within the repository, you will be prompted for permission to overwrite it
if it has changed, unless the `--yes` option is given (see above).

#### The `coc`-command (Code Of Conduct)

```
$ sandhog coc --help
Usage: coc [options]

Generates a CODE_OF_CONDUCT.md file

The `coc` command will generate or update a Code Of Conduct file based on the [Contributor Covenant v1.4.1](https://www.contributor-covenant.org/).
All project maintainers listed in the `package.json` (either through the `author` or `contributors` fields) file located in the repository root will be
marked as Code Of Conduct enforcers. If a `CODE_OF_CONDUCT.md` file already exists within the repository, you will be prompted for permission to overwrite it
if it has changed, unless the `--yes` option is given (see above).

#### The `all`-command

```
$ sandhog all --help
Usage: all [options]

Generates all of the files sandhog supports in one command

The `all` command will generate or update each of the files that Sandhog can generate in a single command.

This is useful if you usually call each and every Sandhog command individually, for example between releases.

The behavior of the individual options is described in the other sections above.

### Readme structure

The README is the heart of your Open source repository. The same goes for Sandhog.
When you run the `readme` command, a README will be generated (or your existing README will be upgraded) to a structure that includes section markers that looks something like this:

```markdown

## FAQ

```

The area inside the START- and END comments is _dynamic_ and will be overridden for each time the `readme` command is run. This makes your README _living_, in the sense that
Sandhog can inject, remove, or even alter existing sections based on changes in your repository such as when you get new maintainers, you change your code style, your logo is updated, or something else.

The static parts of your README is anything not surrounded by those START- and END comments. These are the parts where you can write freely. Don't worry - those parts won't be overridden by Sandhog.

### Readme sections

There are numerous possible README sections. You can exclude those you don't want, either via [a CLI option to the `readme` command](#the-readme-command), or via [a Sandhog config](#configuration).
Some of those sections may only be relevant if your project is in a state that allow them.

#### `toc` (Table of Contents)

The _Table of Contents_ section is auto-generated and will look at the contents of your README and generate a fully-fledged Table of Contents with relative links to the various sections of your README.
This gives the readers of your README an easy way of getting an overview as well as navigating your README.

### `logo`

The _logo_ section is auto-generated and will appear at the very top of your README and give your readers immediate visual feedback. This section won't appear if you don't provide a logo in the [as a config option](#configuration).

### `badges`

The _badges_ section is auto-generated and will appear immediately below the logo (if it has any) in your README and will vary depending on the state of your project as well as your [configuration](#configuration).

The following badges are possible:

| Badge | Description |
| -------------------------- | --------------------------------------------------------------------------------- |
| `downloads` | The amount of times your package has been downloaded within the past month |
| `dependencies` | The status of your project dependencies (e.g. whether or not they are up-to-date) |
| `npm` | The published NPM version of your project |
| `contributors` | The amount of contributors your project has |
| `license` | The discovered license of your project (if it has any) |
| `code_style` | Shows the discovered code style(s) of your project |
| `patreon` | Encourages donations to you via Patreon |
| `open_collective_donate` | Encourages donations to your project via Open Collective |
| `open_collective_backers` | Shows the amount of Open Collective backers |
| `open_collective_sponsors` | Shows the amount of Open Collective sponsors |

### `description_short`

The _description_short_ section is auto-generated and will show the `description` property of your `package.json` as a citation. It should be short and catchy for maximum effect.

### `description_long`

The _description_long_ section is where you can explain what your project is all about. This section is completely free for you to write.

### `features`

The _features_ section is where you can list some highlights of your project. This section is completely free for you to write.

### `feature_image`

The _feature_image_ section is auto-generated and will only be visible if you provide a feature image [as a config option](#configuration).
This should preferably be a static image or even better, an animation showing your project in action.

### `install`

The _install_ section is auto-generated and provides instructions on how to install your library via NPM and Yarn.

### `usage`

The _usage_ section is where you can provide instructions on how to actually use your project/library/tool/framework/app. This section is completely free for you to write.

### `contributing`

The _contributing_ section is auto-generated and will only appear if your project has a `CONTRIBUTING.md` file (which can be generated [via the `contributing` command](#the-contributing-command)).
This section will simply reference the `CONTRIBUTING.md` file so that readers know that your project is contribution-friendly.

### `maintainers`

The _maintainers_ section is auto-generated and lists all of the project maintainers found in the `package.json` file (via the `author` and/or `contributors` fields) in a nice table format.
See [this section](#additional-metadata-for-packagejson-fields) for the full reference of the possible metadata that can be shown in this section.

### `faq`

The _faq_ section is where you can address common (or anticipated) questions that have arisen or may arise in the future. This section is completely free for you to write.

### `backers`

The _backers_ section is auto-generated and includes image grids of your sponsors/backers on Patreon and Open Collective. Because these grids are pure images, they require no manual maintenance
and will immediately reflect any changes to your existing pool of backers and sponsors.

### `license`

The _license_ section is auto-generated and will only appear if a license could be found within your repository. It lists the license, copyright year, and copyright holder of your project.

## Contributing

Do you want to contribute? Awesome! Please follow [these recommendations](./CONTRIBUTING.md).

### FAQ

#### Do you support custom templates?

No, Sandhog is quite opinionated about the files that are being generated and updated.
However, you _can_ exclude sections and badges from the README as described [in this section](#configuration-options)

#### How do you determine the Code Style of the project?

By looking for several things, including:

- Your project dependencies and general fields in `package.json`
- The configs that are being extended in your `eslint.json`/`.eslintrc` (if any such file exists) or any of its ancestors.
- Whether or not your project has a Prettier config.

## License