npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

http-status-check

v1.0.2

Published

Utility to check the HTTP status of URL endpoints

Downloads

22

Readme

HTTP Status Check

![Gitter](https://badges.gitter.im/Join Chat.svg)

Build Status Code Climate Dependency Status

Checks your sites' HTTP statuses

Install

npm install http-status-check

##Run

node index.js

To show only failures in the output:

node index.js --only-output-failures

##Questions?

Feel free to contact me on twitter if you have any questions: @wildfiction

##Objectives

The objectives of the http-status-check project are as follows:

  • Provide a fully-functional utility that most web developers will find useful for keeping tabs on the health of web sites that they are responsible for.
  • Provide an example codebase that can be used in workshops and presentations for developers who are learning Node.js
  • Provide examples of how a Node.js project can be structured, tested and reported on.
  • Provide a safe and encouraging environment for developers who are new to Open Source development to get their feet wet in contributing for the first time (through pull requests).
  • Maintain 100% coverage and demonstrate that this might not just be a vanity metric.

##Getting Started

Running node index.js should give you an indication of how it works. It uses the samplesites.js file for the names of the sites to test.

Copy samplesites.js to checksites.js. If checksites.js is found then it takes precedence over samplesites.js.

Now edit checksites.js and replace the sites with your own sites that you want to run checks on.

##checksites.js config file

The samplesites.js file is heavily commented and a good starting point.

  • sites - an array of sites that will be checked
    • name - any name that you want to give this site. This will be logged to the console with the status.
    • expectedStatus - the status that you expected this site to return, e.g. 200 or 301
    • requestUrl - URL or array of URLs to of the site(s) to check
    • responseHeaders - an object with a collection of response headers expected back from the site. Each of these is compared to the actual response headers received.
    • requestHeaders - an object with a collection of request headers to send with the request.
    • disabled - defaults to false. Set to true if you don't want this site to be checked. Useful if you don't want to delete the details from the checksites.js config file but also don't want it run. Will appear in reports as "not run."
    • excludedHeaders - An array of headers that you expect not to be returned by the server. (For example, for security you may not want the X-Powered-By header to be returned.) If any of these headers are present then the check will be considered a failure and reported as such.
    • followRedirect - If a URL returns redirect status (300 to 399) then continue to follow any redirects and don't check until an non-300 series status is returned. See samplesites.js for use case and further details.
    • expectedText - A string or an array of strings or an array of objects. If an array of objects then each object should have a string 'text' property and an optional boolean caseSensitive property
      • text - The text to find on the page
      • caseSensitive - true/false to indicate if the comparison should be case sensitive. Defaults to false if missing and if expectedText is a string or array of strings.
  • concurrentRequests - The number of sites to check at the same time. Defaults to 3 if this is missing
  • allSites - Data that will be applied to each of the site objects above if it is missing from the site object. i.e. the data in the site object will take precedence over this data.

Enhancements and Bugs

Add requests for enhancements and bugs to: HTTP Status Check Issues

Contribute

You are encouraged to fork this repository, edit the code, and submit a pull request to have your changes included. Even if you have never done this before and it seems scary. Especially if you have never done this before. One of the objectives of this project is to provide a safe and encouraging project where new comers can learn about the mechanics of open source, GitHub source control and coding in JavaScript.

If you are completely new then the best place to start is to start by seeing if you can add a unit test to the project. A test will improve the quality and health of the project and not break anything that anyone is using. You can also add comments and debug() statements to existing tests as you read understand and learn the code. There's also nothing wrong in adding a question in the code if something isn't obvious. Hopefully someone will replace your question with an explanation of how that section of code works.

Once you feel comfortable then try and improve existing code. The unit tests should protect you against making mistakes. You can try and find inefficiencies or better ways to do something. For example, replace a loop with a lodash method.

Have a look at the code coverage and see if you can find some code that hasn't been covered by a test and fill that gap.