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

check-all-the-errors

v1.1.0

Published

Load a bunch of pages, check for errors

Downloads

25

Readme

check-all-the-errors

Loads a bunch of urls and reports on any errors generated by the browser. In particular JavaScript errors, bad urls (images, css), bad links, etc...

You give it a base path and an optional sub path. Example

check-all-the-errors /Users/me/three.js "examples/*.html"

Which will serve the folder /Users/me/three.js and test all the .html files in /Users/me/three.js/examples by loading them as http://localhost:8080/example/somepage.html.

The point is say you update a dependency or make a major search and replace change, then you can run this too see if anything on your site broke.

I suspect it's of limited use. Most complex sites have a real testing suite and require far more manipulation of pages (clicking buttons etc) but for a mostly static site something simple like this might be useful.

Note you can also run it on a remote site by giving it urls. Example

check-all-the-errors --follow-links=local https://threejs.org

Similarly you can test it with some other server. For example

& servez /path/to/website
check-all-the-errors --follow-links=local http://localhost:8080/index.html

This is especially useful if your server does things like respond to path to a folder with index.php or whateveryouconfigured.somext.

Note: I can also be helpful to generate/create your own page of links. For example threejsfundamentals.org's site builder generates a page with links to each language. since there are no natural links across languages. Passing that page with --follow-links=local will end up finding all pages on the site. Of course you could also pass in each of those pages but then if new languages are added you'd have to manually update your configuration.

Installation

npm install -g check-all-the-errors

Usage

check-all-the-errors [options] path-to-serve [...glob]

NOTE: all globs and ignore-patterns are relative to path-to-serve which means you generally need to quote them so the shell does not expand them in place.

examples:

check-all-the-errors somedir              # eqv: somedir/*.html
check-all-the-errors somedir "*.html"     # eqv: somedir/*.html
check-all-the-errors somedir "**/*.html"  # eqv: somedir/**/*.html
check-all-the-errors somedir "foo/*.html" # eqv: somedir/foo/*.html

Options

  • --help displays help

  • --port=<num> port (default: 8080), will chose this or higher

  • --timeout=<ms> the default timeout in ms (default: 20000)

  • --ignore-pattern=<glob> a glob pattern to ignore (see glob node)

  • --config=<config-file> a config JavaScript file

  • --verbose print console.log from browser

  • --output output results to file as json

  • --dry-run just print the initial list of files.

  • --follow-links=<type> follow links (local, remote, both, none)

    note: local links will be loaded and checked for errors, remote links will only be checked for a valid response (200-299).

Config file

The config file's main purpose is to specify expected errors. For example you have a tutorial that shows loading an image cross origin fails. That would normally show up as an error but you can specify in the config file to ignore that error on a per page basis.

Example config

module.exports = {
  expectedErrors: [
    {
      filter: "webgl-3d-textures.html",
      errors: [
        { type: 'msg', test: "gl.INVALID_OPERATION in generateMipmap", },
      ],
    },
    {
      filter: "webgl-data-textures.html",
      errors: [
        { type: 'msg', test: "gl.INVALID_OPERATION in texImage2D", },
      ],
    },
    {
      filter: "webgl-cors-permission.html",
      errors: [
        { type: 'msg', test: /Uncaught SecurityError.*?cross-origin data/, },
        { type: 'msg', test: "JSHandle@error", },
        { type: 'pageerror', test: "DOMException: Failed to execute 'texImage2D", },
      ],
    },
    {
      filter: "webgl-cors-permission-bad.html",
      errors: [
        { type: 'pageerror', test: "DOMException: Failed to execute 'texImage2D", },
      ],
    },
  ]
};

expectedErrors is an array of tests, each test has a filter which is used to match the expected errors to a specific page. filter can be a string, in which case if the URL contains that substring it will match. filter can be regular expression. filter can also be a function which will be passed the URL as a string and should return true if it's a match.

If it is a match then there is an array of errors. Each error has a type which must match one of msg, exception error, pageerror, badlink, or badResponse. Each error also as a test which like filter can be a string, regular expression, or function. If the test passes the error is ignored.

License

MIT