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

@thetimes/jest-lint

v1.4.0

Published

A tool to analyse/validate jest snapshots

Downloads

16

Readme

Coverage Status Build Status

jest-lint

A linter for Jest snapshots to help you write (in a very opinionated way) "better" snapshots

Install

Install globally or locally

yarn add --dev @thetimes/jest-lint

Run

Just run jest-lint in any directory where snap files may lurk for a report

The Code

The linter essentially has four stages for each discovered snap file:

Parse => Analyse => Report => Output

Parse

In this phase it takes the Jest snapshot and turns it into a JavaScript Object

Analyse

Using predefined rules it builds up a list of errors and warnings, the thresholds of which can be optionally overridden. These errors and warnings exist at both the snapshot file level itself as well as for each test within the file

To configure the rules create a .jestlint file with your overrides e.g.

{
  "maxFileSize": 5000,
  "genericAttributes": [
    "randomProp",
    "fixedProp"
  ],
  "genericValues": [
    "[Function]"
  ]
}

Report

The report phase is split out from the analysis to enable the previous step to be performed and written to disk (which is relatively fixed), allowing you to iterate on different criteria to get the right balance for your codebase

Output

Currently the only output is via the console with a litany of red, yellow and green writing

File Rules

MaxFileSizeError

config option: maxFileSize: number

default: 10,000

Choose the maximum file size for your snapshots, large snapshot files are hard to diff and/or view on GitHub

Test Rules

GenericAttributeError

config option: genericAttributes: string[]

default: []

There are many props, for example in FlatList that are just noise on a snapshot rather than providing value to the component under test. Use this to weed out props that aren't of use in a snapshot

GenericValueError

config option: genericValues: string[]

default: ["Function"]

There are many values such as [Function] that don't provide real value in a snapshot which can be excluded without detriment to the test, thus removing more noise

MaxAttributeError

config option: maxAttributes: number

default: 5

If an element has too many attributes then it's unlikely everyone is vital to the component under test and will end up contributing to changes not related to the test when things change

MaxAttrArrayLengthError

config option: maxAttributeArrayLength: number

default: 5

If a prop has a value that is very long it is unlikely the whole value is of interest to the test and can be shortened for easier diffing, certainly for lists

MaxAttrStringLengthError

config option: maxAttributeStringLength: number

default: 32

If a prop has a value that is very long it is unlikely the whole value is of interest to the test and can be shortened to an example for easier diffing

MaxDepthError

config option: maxDepth: number

default: 10

Deep nesting of elements is likely a sign of trying to test leaves that should have their own tests without the rest of the snapshot. It is also likely that they're external dependencies that will break many snapshots when they change but not related to the test

MaxLinesError

config option: maxLines: number

default: 300

Perhaps the strongest barometer of an unspecific snapshot test is it's length. A long snapshot is hard to read, hard to diff and is likely to change between PRs not related to the tests

MaxGenericElementWarning

config option: maxGenericElements: number

default: 10

If a snapshot is filled with primitives with no props it is likely that either there are too many of them in general or the test isn't specific enough. For example 15 div elements suggest a lot of "div noise" rather than a specific render test

Additional config options

snapPattern: string

default: **/*.js.snap

This is relative to the cwd