View sandhog on Snyk Open Source Advisor

Package Health Score

60 / 100

security
Security review needed
popularity
Limited
maintenance
Sustainable
community
Sustainable

Explore Similar Packages

Security

Security review needed

All security vulnerabilities belong to production dependencies of direct and indirect packages.

Security and license risk for significant versions

All Versions

Version				Vulnerabilities	License Risk
3.0.2	\|	10/2024	Popular	0 C 0 H 0 M 0 L	0 H 0 M 0 L
2.0.2	\|	05/2022		0 C 0 H 0 M 0 L	0 H 0 M 0 L
1.0.44	\|	05/2022		0 C 0 H 0 M 0 L	0 H 0 M 0 L

License

MIT

Security Policy

Is your project affected by vulnerabilities?

Scan your projects for vulnerabilities. Fix quickly with automated fixes. Get started with Snyk for free.

Get started free

Popularity

Limited

Weekly Downloads (30)

GitHub Stars: 15
Forks: 1
Contributors: 1

Direct Usage Popularity

The npm package sandhog receives a total of 30 downloads a week. As such, we scored sandhog popularity level to be Limited.

Based on project statistics from the GitHub repository for the npm package sandhog, we found that it has been starred 15 times.

Downloads are calculated as moving averages for a period of the last 12 months, excluding weekends and known missing data points.

Community

Sustainable

Readme.md: Yes
Contributing.md: Yes
Code of Conduct: Yes
Contributors: 1
Funding: Yes

This project has seen only 10 or less contributors.

Embed Package Health Score Badge

Maintenance

Sustainable

Commit Frequency

Open Issues: 0
Open PR: 4
Last Release: 1 month ago
Last Commit: 22 days ago

Further analysis of the maintenance status of sandhog based on released npm versions cadence, the repository activity, and other data points determined that its maintenance is Sustainable.

We found that sandhog demonstrates a positive version release cadence with at least one new version released in the past 3 months.

In the past month we didn't find any pull request activity or change in issues status has been detected for the GitHub repository.

Keep your project healthy

Check your package.json

Ensure all the packages you're using are healthy and well-maintained

Snyk Vulnerability Scanner

Get health score & security insights directly in your IDE

Package

Node.js Compatibility: >=18.20.0

Age: 4 years
Dependencies: 10 Direct
Versions: 14
Install Size: 654 kB
Dist-tags: 1
# of Files: 46
Maintainers: 1
TS Typings: Yes

sandhog has more than a single and default latest tag published for the npm package. This means, there may be other tags available for this package, such as next to indicate future releases, or stable to indicate stable releases.

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

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

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&lt;
        | "toc"
        | "logo"
        | "badges"
        | "description_short"
        | "description_long"
        | "features"
        | "feature_image"
        | "usage"
        | "install"
        | "contributing"
        | "maintainers"
        | "faq"
        | "backers"
        | "license"
      &gt;;
    };
    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&lt;
        | "downloads"
        | "dependencies"
        | "npm"
        | "contributors"
        | "license"
        | "patreon"
        | "open_collective_donate"
        | "open_collective_backers"
        | "open_collective_sponsors"
        | "code_style"
      &gt;;
    };
  };
  // 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:

// Inside package.json
{
  contributors: [
    {
      name: "John Done",
      email: "john@doe.com",
      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 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

  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
    -h, --help           output usage information

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.

It will take the Patreon and Open Collective information if given in the Sandhog config, 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 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

  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
    -h, --help           output usage information

The contributing command will generate or update a CONTRIBUTING.md file in a friendly language. See this file 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

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
  -h, --help           output usage information

The coc command will generate or update a Code Of Conduct file based on the Contributor Covenant v1.4.1. 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

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
  -h, --help           output usage information

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:



## 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, or via a Sandhog config. 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.

`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.

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. 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). 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 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.

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

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

MIT ©

sandhog dependencies

@inquirer/prompts ansi-colors commander eslint json5 @effect/markdown-toc prettier yaml helpertypes crosspath

FAQs

What is sandhog?

A virtual Open Source project maintainer. Visit Snyk Advisor to see a full health score report for sandhog, including popularity, security, maintenance & community analysis.

Is sandhog popular?

The npm package sandhog receives a total of 30 weekly downloads. As such, sandhog popularity was classified as limited. Visit the popularity section on Snyk Advisor to see the full health analysis.

Is sandhog well maintained?

We found indications that sandhog maintenance is sustainable demonstrating some project activity. We saw a total of 1 open source contributors collaborating on the project. See the full package health analysis to learn more about the package maintenance status.

Is sandhog safe to use?

While scanning the latest version of sandhog, we found that a security review is needed. A total of 0 vulnerabilities or license issues were detected. See the full security scan results.

Last updated on 21 November-2024, at 11:30 (UTC).

Build a secure application checklist

Select a recommended open source package

Minimize your risk by selecting secure & well maintained open source packages

DONE

Scan your app for vulnerabilities

Scan your application to find vulnerabilities in your: source code, open source dependencies, containers and configuration files

SCAN NOW

Fix identified vulnerabilities

Easily fix your code by leveraging automatically generated PRs

AUTO FIX

Monitor for new issues

New vulnerabilities are discovered every day. Get notified if your application is affected

MONITOR APP

Package Health Score

Explore Similar Packages

Security and license risk for significant versions

Is your project affected by vulnerabilities?

Weekly Downloads (30)

Direct Usage Popularity

Embed Package Health Score Badge

Commit Frequency

Keep your project healthy

Check your package.json

Snyk Vulnerability Scanner

Readme

Description

Features

Backers

Patreon

Table of Contents

Install

npm

Yarn

pnpm

Run once with npx

Engine

Usage

Configuration

Configuration options

Additional metadata for package.json fields

CLI

The readme-command

The license-command

The funding-command

The contributing-command

The coc-command (Code Of Conduct)

The all-command

Readme structure

Readme sections

toc (Table of Contents)

logo

badges

description_short

description_long

features

feature_image

install

usage

contributing

maintainers

faq

backers

license

Contributing

FAQ

Do you support custom templates?

How do you determine the Code Style of the project?

License

sandhog dependencies

sandhog development dependencies

FAQs

What is sandhog?

Is sandhog popular?

Is sandhog well maintained?

Is sandhog safe to use?

Build a secure application checklist

Select a recommended open source package

Scan your app for vulnerabilities

Source Code

Open Source

Container

Config

Fix identified vulnerabilities

Monitor for new issues

Additional metadata for `package.json` fields

The `readme`-command

The `license`-command

The `funding`-command

The `contributing`-command

The `coc`-command (Code Of Conduct)

The `all`-command

`toc` (Table of Contents)

`logo`

`badges`

`description_short`

`description_long`

`features`

`feature_image`

`install`

`usage`

`contributing`

`maintainers`

`faq`

`backers`

`license`