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

chromatica

v0.1.3

Published

> A small wrapper for puppeteer to enable even faster headless chrome testing

Downloads

36

Readme

chromatica

A small wrapper for puppeteer to enable even faster headless chrome testing

Build Status

This is a small, personal project I put together to help me get basic browser testing enabled a lot more quickly and with a whole lot less boilerplate. Essentially it's just a class that puts a layer of abstraction over puppeteer and incorporates a simple http server automatically. The idea is, you drop in a couple server configuration options, grab a page reference, and get testing.

Here's how it works

First, figure out what testing framework you want to use. In this case, we'll assume we're using mocha.

Next, you'll need to make sure you have at least one HTML template you can use to serve up to headless chrome. If you are testing a website, chances are you'll have a lot of these already. If you're testing pure javascript (for example, if you're building a DOM manipulation library or something), you may need to create a template. Here's an example:

<!DOCTYPE html>
<html lang="en" dir="ltr">
  <head>
    <meta charset="utf-8">
    <title>Test</title>
  </head>
  <body>
    <div id="foo"></div>
    <script src="/path/to/my-test-code.js"></script>
  </body>
</html>

Inside one of your actual test files, import chromatica and get your configuration options ready. What we're doing here is configuring the chromatica server to serve up the right files when it gets requests from chrome.

const fs = require('fs')
const assert = require('assert')
const Chromatica = require('chromatica')

const serverPort = 3000 // or whatever you want. Default is 3000
const serverRoutes = [
  {
    test: /my-test-code\.js$/,
    file: fs.readFileSync('/path/to/my-test-code.js')
  },
  {
    test: null,
    file: fs.readFileSync('/path/to/my-test-html-template.html')
  }
]

In this example, when headless chrome attempts to navigate to /, it'll match the null test (which is a catch-all) and it'll be sent our HTML template. When it loads up that file and makes a request for /path/to/my-test-code.js, the request will match our other regex test and the server will hand over the JS file.

Now it's time to start writing tests.

The simplest way to get things running is to "turn on" chromatica at the beginning of a set of tests and then "turn it back off" when the tests are through. In that case, we can write something like this:

describe('some tests', function () {

  before(async function () {
    this.chromatica = new Chromatica({
      port: serverPort,
      routes: serverRoutes,
      // This object is passed straight to puppeteer.launch
      launch: { args: ["--disable-dev-shm-usage"] }
    })
    this.page = await this.chromatica.getPage()
  })

  after(async function () {
    await this.page.close()
    await this.chromatica.closeBrowser()
  })

  it('loads the html template', async function () {
    const result = await this.page.evaluate(() => !!document.querySelector('#foo'))
    assert.ok(result)
  })

})

Here we see nearly all of chromatica's functionality at work. Creating a new Chromatica spins up a server that's ready to work with headless chrome. Calling getPage opens the browser if it isn't already open and returns a new page via puppeteer. Calling closeBrowser closes all open pages, shuts down headless chrome, and shuts down the server it was talking to.

Once you have a page object, you're dealing with the raw object produced by puppeteer so if you want to know what methods it has available to it, check out the puppeteer docs. Most of the time, you'll just want to evaluate something on the page. If you want to configure the page (specifying, for instance, whether or not to wait until the network is idle, etc), you can pass in an object of puppeteer page options to getPage. For example:

this.chromatica.getPage({
  waitUntil: 'networkidle0' // This is also a default option
})

By default, when you call getPage, chromatica will navigate your page to http://localhost:<YOUR_PORT_NUMBER>, assuming that you have provided a null route that serves up an HTML template. If you would like to change this, just add a path field to your options object:

this.chromatica.getPage({
  waitUntil: 'networkidle0',
  path: '/my-page.html'
})