DEV Community: Ryan Yost

How to level-up your Cypress testing

Ryan Yost — Thu, 19 Mar 2020 00:52:20 +0000

This is a tutorial about cypress-testing-library, waiting for network requests, custom commands, piping console logs to the test/terminal output and failing tests when there's a console error.

Cypress for end-to-end testing is awesome and easy to get started with. But once you've written more than a few tests, you'll start to realize ways to improve your test infrastructure and implementations. Here are 5 techniques I've picked up that made huge improvements to my Cypress testing.

We'll walk through 5 techniques

Use cypress-testing-library
Wait explicitly for network requests
Turn common actions into commands
Log browser warnings and errors in the terminal output
Fail tests when there's an unknown console error

Set up the test project

Create a new React project with create-react-app and cd into it.

npx create-react-app cypress-tutorial
cd cypress-tutorial

Install cypress.

npm i -D cypress

Initialize cypress in your project by opening the development GUI for the first time.

npx cypress open

Delete the example test directory.

rm -R ./cypress/integration/examples

Run the app in a terminal window and keep it running at http://localhost:3000 throughout the tutorial.

npm start

Add ESLint and the Cypress linting rules

To avoid annoying linting issues with Cypress in your IDE, let's setup linting such that it understands Cypress's global cy object.

npm i -D eslint eslint-plugin-cypress

Create an .eslintrc.json.

touch .eslintrc.json

Paste this code into your .eslintrc.json so that your IDE can understand the Cypress code and modern JavaScript.

{
  "plugins": ["cypress"],
  "env": { "es6": true }
}

Write a basic test

To have a starting point for implementing more advanced techniques, let's write a super basic test.

Create a new test file called tutorial.spec.js.

touch ./cypress/integration/tutorial.spec.js

Paste the following Cypress test code into the tutorial.spec.js file. All this test does is make sure the app works by looking for the CRA boilerplate "Learn React" link.

NOTE: Normally, you'd set the baseUrl in cypress.json!

describe("Cypress Tutorial", function() {
  it("works", function() {
    cy.visit("http://localhost:3000");
    cy.get("a").contains("Learn React");
  });
});

Run the test by opening the GUI with npx cypress open and see that the test passes.

Technique 1: Use cypress-testing-library

You may have heard of Kent C. Dodds and his testing libraries like dom-testing-library and react-testing-library. Well there's one for cypress, too, called cypress-testing-library and it's pretty sweet for easily writing tests in a way that more closely mimics how a user will actually interact with your app, which means your
tests are better.

Install the library.

npm install -D @testing-library/cypress

Per the docs, we need to import the library into cypress/support/commands.js for it to work. So update that file with the following...

import "@testing-library/cypress/add-commands";

Now we have access to the awesome commands from cypress-testing-library right from the cy object just like normal commands. Let's use one in our existing tutorial.spec.js test.

describe("Cypress Tutorial", function() {
  it("Makes sure the app is working", function() {
    cy.visit("http://localhost:3000");
    cy.findByText("Learn React"); // formerly cy.get("a").contains("Learn React");
  });
});

Not much changed, but now we aren't looking for an a tag anymore, merely anything on the page that has Learn React. This way of looking for it is closer to how a user will read and interact with the screen. You can
read more about that concept here.

And to make sure our test actually works and breaks when it's supposed to, change the text to search for Learn Vue and see the test break in the GUI.

Technique 2: Wait explicitly for network requests

I've found that network requests are the biggest cause of flakiness in tests. Sometime they're quick, other times they exceed your default timeout and cause your test to fail. While you could just increase the timeout, that makes your tests longer than they need to be. There's a better way.

Add a network request to the React app

We need a network request to test, so let's add a dummy one to the App.js file. Also, for some reason the native fetch api doesn't work with cypress route stuff, so let's install and use axios.

npm i axios

Now paste this in App.js.

import React, { useState, useEffect } from "react";
import axios from "axios";
import logo from "./logo.svg";
import "./App.css";

function App() {
  const [loaded, setLoaded] = useState(false);

  useEffect(() => {
    const secondsToWait = 5;
    axios(`https://httpstat.us/200?sleep=${secondsToWait * 1000}`).then(
      response => {
        setLoaded(true);
      }
    );
  }, []);

  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        {loaded ? (
          <a
            className="App-link"
            href="https://reactjs.org"
            rel="noopener noreferrer"
          >
            Learn React
          </a>
        ) : null}
      </header>
    </div>
  );
}

export default App;

With the updates above, the app now doesn't show the "Learn React" link until the network request finishes after 5 seconds. Check it out for yourself by reloading your app at http://localhost:3000.

Because the "Learn React" link doesn't show up for 5 seconds, which is longer than Cypress' default timeout, the test now fails.

The bad fix: increasing the timeout

One suboptimal way to "fix" your test would be to increase the default timeout of the findByText command, like below.

describe("Cypress Tutorial", function() {
  it("Makes sure the app is working", function() {
    cy.visit("http://localhost:3000");
    cy.findByText("Learn React", { timeout: 10000 });
  });
});

Now your test passes, but it waits for the network request for 10 seconds every time you run the test - even if the network only needs 2 seconds. That's a lot of time to add to your test suite - multiplied by however many times you use this strategy!

The better fix: alias and wait

Cypress has a thing called aliases that let you explicitly reference various things in your tests like elements, fixtures
and, in our case, network requests!

Let's improve our test by aliasing the network request and waiting for it before looking for the "Learn Text" link.

describe("Cypress Tutorial", function() {
  it("works", function() {
    cy.server();

    // alias the network request
    cy.route("/200?**").as("fakeNetworkRequest");

    cy.visit("http://localhost:3000");

    // wait for the network request to complete
    cy.wait("@fakeNetworkRequest");

    // now look for the link
    cy.findByText("Learn React");
  });
});

Some explanations/things to note about the above...

cy.server() lets you "start a server to begin routing responses to cy.route() and to change the behavior of network requests."
cy.route() lets you manage network behavior and takes an explicit url or a glob to match certain request patterns. You can also get more specific with a config object, which is what I chose to do above.

Now our test passes and waits only as long as it needs to, even if you increase the secondsToWait in App.js!

Technique 3: Turn common actions into commands

As you write more and more tests, you'll find that you're reusing a lot of the same logic for doing common interactions like...

logging into your app
selecting weird elements
navigating to a page
prepping some data/state on the page
much more...

Our tutorial app and test are really simple - but this wouldn't be a tutorial without a convoluted example to show off some technology!

So let's write a new test that checks that the "Learn React" href is "https://reactjs.org". In that test, we'll use some reusable commands that we create.

Write the new tests, without any commands

In the same describe block as the first test, add this one. Obviously very similar to the first, so we'll extract out the common bits shortly.

it("has a link pointing to the react website", function() {
    cy.server();
    cy.route("/200?**").as("fakeNetworkRequest");

    cy.visit("http://localhost:3000");

    cy.wait("@fakeNetworkRequest");

    cy.findByText("Learn React").should(
      "have.attr",
      "href",
      "https://reactjs.org"
    );
});

Run that test in the GUI to make sure it passes.

Our first command

We may have a reason to verify the href of links in other tests, which we could extract out into a nice, custom Cypress command.

Obviously your real world app and tests will provide more legit reasons to write reusable commands.

Open up cypress/support/commands.js and add the below code, a.k.a. our custom command.

import "@testing-library/cypress/add-commands"; //same as before for cypress-testing-library

Cypress.Commands.add("verifyLink", (linkText, href) => {
  cy.findByText(linkText).should("have.attr", "href", href);
});

So we just added a command verifyLink that takes two args - the linkText to look for and the href the link should have.

Go back to tutorial.spec.js and use the command!

it("has a link pointing to the react website", function() {
  cy.server();
  cy.route("/200?**").as("fakeNetworkRequest");

  cy.visit("http://localhost:3000");

  cy.wait("@fakeNetworkRequest");

  cy.verifyLink("Learn React", "https://reactjs.org");
});

Bonus: Use beforeEach to reuse test code within the same test suite.

Sometimes test code is repeated just within a spec file/suite, which we can extract out with options like beforeEach, afterEach, and sometimes just good ole fashioned JavaScript functions.

Here in tutorial.spec.js, we'll leverage beforeEach. Below is the latest version of our test suite.

describe("Cypress Tutorial", function() {
  beforeEach(function() {
    cy.server();
    cy.route("/200?**").as("fakeNetworkRequest");

    cy.visit("http://localhost:3000");

    cy.wait("@fakeNetworkRequest");
  });

  it("works", function() {
    cy.findByText("Learn React");
  });

  it("has a link pointing to the react website", function() {
    cy.verifyLink("Learn React", "https://reactjs.org");
  });
});

Technique 4: Log browser warnings and errors in the headless/terminal output

When you run the Cypress test suite in headless mode, it's nice to be able to see console warnings and errors that may help you debug why your tests failed. This doesn't happen by default in the terminal output, so let's make it happen.

Add a console warning and error to the app

First, we'll need errors and warnings to pass through to the terminal. So update App.js with the following code...

//... same above
function App() {
  const [loaded, setLoaded] = useState(false);

  useEffect(() => {

    console.log("This is a log");
    console.warn("This is a warning");
    console.error("This is an error");

    const secondsToWait = 1;
    axios(`https://httpstat.us/200?sleep=${secondsToWait * 1000}`).then(
      response => {
        setLoaded(true);
      }
    );
  }, []);

//... same below

Check in your browser console for those three messages.

Run the tests in headless mode

To see the terminal test output before it shows console warnings and errors, run the following.

npx cypress run

Logging console output

This is going to seem kinda elaborate for something so simple, but it's worth it and exposes some possibilities in Cypress generally.

Open up cypress/commands/index.js and add the following code to the bottom of the file.

Cypress.on("window:before:load", win => {
  cy.stub(win.console, "error", msg => {
    cy.now("task", "error", msg);
  });

  cy.stub(win.console, "warn", msg => {
    cy.now("task", "warn", msg);
  });
});

There's a decent bit going on here - let's break it down.

Cypress.on is a way to listen for Cypress events,
we run a function on the window:before:load event (basically before the tests run)
To intercept the console methods we stub them.
cy.now is something I learned about here and here and seems to avoid an issue with cy.task and promises that Cypress doesn't like. I wish there was a better way , so if you know of any let me know!

We need to update one more file, cypress/plugins/index.js, to get things to work. Here's the code you'll need in that file, which listens for the tasks we just set up in cypress/commands/index.js and logs to the internal Cypress process (including the terminal output with nice colors).

module.exports = on => {
  on(`task`, {
    error(message) {
      console.error("\x1b[31m", "ERROR:", message, "\x1b[0m");
    },
    warn(message) {
      console.warn("\x1b[33m", "WARNING:", message, "\x1b[0m");
    },
  });
};

Now run the tests in headless mode with npx cypress run and you should see the logs in your terminal output!

Technique 5: Fail tests when there's an unknown console error

Cypress tests fail on uncaught exceptions already, which is basically your app crashing. But sometimes we might want to fail the test when there's a console.error in the browser during the test.

Fortunately, we can easily add this behavior to our Cypress tests with a small addition to the code from the preview section. Open cypress/support/index and update the Cypress.on listener block to match below, which just has one extra line.

Cypress.on("window:before:load", win => {
  cy.stub(win.console, "error", msg => {
    cy.now("task", "error", msg);
    throw new Error(msg); // all we needed to add!
  });

  cy.stub(win.console, "warn", msg => {
    cy.now("task", "warn", msg);
  });
});

No rerun the test suite and see that it fails!

Bonus - ignore known errors

Sometimes we know of console errors that we just can't get rid of, but we want to still fail tests for unknown errors. That's a simple fix by only throwing the Error when we don't recognize the error message. See below for how we can ignore our current app's console error.

Cypress.on("window:before:load", win => {
  cy.stub(win.console, "error", msg => {
    if (msg.includes("This is an error")) {
      return null;
    }

    cy.now("task", "error", msg);
    throw new Error(msg);
  });

  cy.stub(win.console, "warn", msg => {
    cy.now("task", "warn", msg);
  });
});

Rerun the test suite and the console error will no longer fail your tests!

And that's it!

I have more Cypress techniques (like making it work with modern SPA apps/tools like react-router and adding to a CI/CD pipeline) I didn't have space for in this tutorial, so those will be coming soon!

Projects starred by Dan Abramov in the past year

Ryan Yost — Tue, 17 Mar 2020 02:23:46 +0000

Keeping up with all of the cool projects out there is impossible - but seeing what other developers are starring on
GitHub is an easy way to get a feel for what's out there and what's worth checking out.

Want a personalized version of these lists in your inbox every week?

Then sign up for Follow the Stars - a weekly email with the projects that the folks you follow on GitHub have starred
.

list

Description: List of Homeferences

Repo URL: https://github.com/homeferences/list

Repo Owner: homeferences

GitHub Stars: 331

overnight

Description: A soft vibrant VSCode theme - Based on Sarah Drasner's Night Owl and Dan Abramov's Overreacted blog

Repo URL: https://github.com/cevr/overnight

Repo Owner: cevr

GitHub Stars: 252

react-native-website

Description: The site and docs for React Native

Repo URL: https://github.com/facebook/react-native-website

Repo Owner: facebook

GitHub Stars: 1,038

excalidraw

Description: Excalidraw is a whiteboard tool that lets you easily sketch diagrams that have a hand-drawn feel to them.

Repo URL: https://github.com/excalidraw/excalidraw

Repo Owner: excalidraw

GitHub Stars: 3,412

one-click.js

Description: One Click, Offline, CommonJS Modules in the browser

Repo URL: https://github.com/jordwalke/one-click.js

Repo Owner: jordwalke

GitHub Stars: 312

super-rentals-tutorial

Description: null

Repo URL: https://github.com/ember-learn/super-rentals-tutorial

Repo Owner: ember-learn

GitHub Stars: 63

react-dom-mini

Description: Toy React renderer from my React Conf 2019 talk, "Building a Custom React Renderer"

Repo URL: https://github.com/sophiebits/react-dom-mini

Repo Owner: sophiebits

GitHub Stars: 532

react-adaptive-hooks

Description: Deliver experiences best suited to a user's device and network constraints

Repo URL: https://github.com/GoogleChromeLabs/react-adaptive-hooks

Repo Owner: GoogleChromeLabs

GitHub Stars: 4,046

tailwindcss

Description: A utility-first CSS framework for rapid UI development.

Repo URL: https://github.com/tailwindcss/tailwindcss

Repo Owner: tailwindcss

GitHub Stars: 20,701

velcro

Description: A set of tools and libraries for stitching together modules and code in highly dynamic browser environments

Repo URL: https://github.com/ggoodman/velcro

Repo Owner: ggoodman

GitHub Stars: 81

chakra-ui

Description: ⚡️Simple, Modular & Accessible UI Components for your React Applications

Repo URL: https://github.com/chakra-ui/chakra-ui

Repo Owner: chakra-ui

GitHub Stars: 5,425

mobile-first-animation

Description: Gesture-driven animation on the mobile web (React Conf 2019)

Repo URL: https://github.com/aholachek/mobile-first-animation

Repo Owner: aholachek

GitHub Stars: 1,889

react-nodegui

Description: Build performant, native and cross-platform desktop applications with native React + powerful CSS like styling.🚀

Repo URL: https://github.com/nodegui/react-nodegui

Repo Owner: nodegui

GitHub Stars: 4,390

github-do-not-ban-us

Description: GitHub do not ban us from open source world 🇮🇷

Repo URL: https://github.com/1995parham/github-do-not-ban-us

Repo Owner: 1995parham

GitHub Stars: 12,121

talon_configs

Description: Modules to be used with Talon for hands-free input

Repo URL: https://github.com/2shea/talon_configs

Repo Owner: 2shea

GitHub Stars: 69

hermes

Description: Hermes is a small and lightweight JavaScript engine optimized for running React Native on Android.

Repo URL: https://github.com/facebook/hermes

Repo Owner: facebook

GitHub Stars: 5,127

react-firebase-hooks

Description: React Hooks for Firebase.

Repo URL: https://github.com/CSFrequency/react-firebase-hooks

Repo Owner: CSFrequency

GitHub Stars: 953

libra

Description: Libra’s mission is to enable a simple global currency and financial infrastructure that empowers billions of people.

Repo URL: https://github.com/libra/libra

Repo Owner: libra

GitHub Stars: 14,025

rehp

Description: ReHp

Repo URL: https://github.com/jordwalke/rehp

Repo Owner: jordwalke

GitHub Stars: 165

react-teleporter

Description: Teleport React components in the same React tree 📡

Repo URL: https://github.com/gregberge/react-teleporter

Repo Owner: gregberge

GitHub Stars: 881

devhub

Description: TweetDeck for GitHub - Filter Issues, Activities & Notifications - Web, Mobile & Desktop

Repo URL: https://github.com/devhubapp/devhub

Repo Owner: devhubapp

GitHub Stars: 6,588

react-vertex

Description: ◾ React Vertex | Hooks-based WebGL library for React

Repo URL: https://github.com/sghall/react-vertex

Repo Owner: sghall

GitHub Stars: 1,216

build-tracker

Description: A set of tools to track the size of your build artifacts over time.

Repo URL: https://github.com/paularmstrong/build-tracker

Repo Owner: paularmstrong

GitHub Stars: 367

empathy-driven-development

Description: Demo Gatsby app for a #noSlides talk on debugging and building accessible React apps

Repo URL: https://github.com/marcysutton/empathy-driven-development

Repo Owner: marcysutton

GitHub Stars: 319

pastel

Description: 🎨 Framework for effortlessly building Ink apps

Repo URL: https://github.com/vadimdemedes/pastel

Repo Owner: vadimdemedes

GitHub Stars: 1,173

glicky

Description: 🐭 An In-browser User Interface For JavaScript Development Workflows

Repo URL: https://github.com/alex-saunders/glicky

Repo Owner: alex-saunders

GitHub Stars: 840

React95

Description: 🌈🕹 Refreshed Windows 95 style UI components for your React app

Repo URL: https://github.com/arturbien/React95

Repo Owner: arturbien

GitHub Stars: 3,602

playroom

Description: Design with JSX, powered by your own component library.

Repo URL: https://github.com/seek-oss/playroom

Repo Owner: seek-oss

GitHub Stars: 3,200

react-loops

Description: React Loops works with React Hooks as part of the React Velcro Architecture

Repo URL: https://github.com/leebyron/react-loops

Repo Owner: leebyron

GitHub Stars: 1,106

is-thirteen

Description: Check if a number is equal to 13.

Repo URL: https://github.com/jezen/is-thirteen

Repo Owner: jezen

GitHub Stars: 5,002

36 projects starred by top JavaScript developers this week

Ryan Yost — Sun, 08 Mar 2020 18:24:18 +0000

Every week I loop through a list of influential/active/known JavaScript developers and see what they've starred on GitHub in the past week. The JS ecosystem is so quick to evolve and tough to keep up with, so hopefully this makes discovering new tools and resources a little easier.

Want a personalized version of these lists in your inbox every week?

Then sign up for Follow the Stars - a weekly email with the projects that the folks you follow on GitHub have starred
.

bundle-buddy

Description: A tool to identify bundle duplication across splits.

Repo URL: https://github.com/samccone/bundle-buddy

Repo Owner: samccone

GitHub Stars: 2,729

inspectpack

Description: An inspection tool for Webpack frontend JavaScript bundles.

Repo URL: https://github.com/FormidableLabs/inspectpack

Repo Owner: FormidableLabs

GitHub Stars: 406

vscode-jumpy

Description: Jumpy Extension for Visual Studio Code

Repo URL: https://github.com/wmaurer/vscode-jumpy

Repo Owner: wmaurer

GitHub Stars: 75

vscode-quick-select

Description: Quick and Simple Jumping Text Selection

Repo URL: https://github.com/dbankier/vscode-quick-select

Repo Owner: dbankier

GitHub Stars: 76

vscode-expand-region

Description: porting sublime-expand-region to visual code

Repo URL: https://github.com/windwp/vscode-expand-region

Repo Owner: windwp

GitHub Stars: 43

prettier-setup

Description: Basic configuration for Prettier, ESLint and Husky.

Repo URL: https://github.com/lipis/prettier-setup

Repo Owner: lipis

GitHub Stars: 144

prettier-eslint

Description: Code ➡️ prettier ➡️ eslint --fix ➡️ Formatted Code ✨

Repo URL: https://github.com/prettier/prettier-eslint

Repo Owner: prettier

GitHub Stars: 2,776

SublimeLinter

Description: The code linting framework for Sublime Text 3

Repo URL: https://github.com/SublimeLinter/SublimeLinter

Repo Owner: SublimeLinter

GitHub Stars: 1,846

vscode-linter-xo

Description: Linter for XO

Repo URL: https://github.com/SamVerschueren/vscode-linter-xo

Repo Owner: SamVerschueren

GitHub Stars: 94

TypeScript-Sublime-Plugin

Description: IO wrapper around TypeScript language services, allowing for easy consumption by editor plugins

Repo URL: https://github.com/microsoft/TypeScript-Sublime-Plugin

Repo Owner: microsoft

GitHub Stars: 1,604

iTerm2-Color-Schemes

Description: Over 200 terminal color schemes/themes for iTerm/iTerm2. Includes ports to Terminal, Konsole, PuTTY, Xresources, XRDB, Remmina, Termite, XFCE, Tilda, FreeBSD VT, Terminator, Kitty, MobaXterm, LXTerminal, Microsoft's Windows Terminal, Visual Studio

Repo URL: https://github.com/mbadolato/iTerm2-Color-Schemes

Repo Owner: mbadolato

GitHub Stars: 15,212

zsh-history-enquirer

Description: plugin for zsh history search, enhance interaction

Repo URL: https://github.com/zthxxx/zsh-history-enquirer

Repo Owner: zthxxx

GitHub Stars: 14

colorls

Description: A Ruby gem that beautifies the terminal's ls command, with color and font-awesome icons. 🎉

Repo URL: https://github.com/athityakumar/colorls

Repo Owner: athityakumar

GitHub Stars: 2,896

fonts

Description: Patched fonts for Powerline users.

Repo URL: https://github.com/powerline/fonts

Repo Owner: powerline

GitHub Stars: 18,578

agnoster-zsh-theme

Description: A ZSH theme designed to disclose information contextually, with a powerline aesthetic

Repo URL: https://github.com/agnoster/agnoster-zsh-theme

Repo Owner: agnoster

GitHub Stars: 2,491

nerd-fonts

Description: Iconic font aggregator, collection, & patcher. 3,600+ icons, 50+ patched fonts: Hack, Source Code Pro, more. Glyph collections: Font Awesome, Material Design Icons, Octicons, & more

Repo URL: https://github.com/ryanoasis/nerd-fonts

Repo Owner: ryanoasis

GitHub Stars: 19,922

fzf

Description: 🌸 A command-line fuzzy finder

Repo URL: https://github.com/junegunn/fzf

Repo Owner: junegunn

GitHub Stars: 27,489

mac-setup-script

Description: script to setup my mac

Repo URL: https://github.com/pathikrit/mac-setup-script

Repo Owner: pathikrit

GitHub Stars: 111

awk-anti-textbook

Description: learn awk by example

Repo URL: https://github.com/thewhitetulip/awk-anti-textbook

Repo Owner: thewhitetulip

GitHub Stars: 524

brunsli

Description: Practical JPEG Repacker

Repo URL: https://github.com/google/brunsli

Repo Owner: google

GitHub Stars: 503

handoff-visualizer

Description: 📶📱🚗 Wireless Network Handoff Visualizer built with React!

Repo URL: https://github.com/chonyy/handoff-visualizer

Repo Owner: chonyy

GitHub Stars: 113

webpack-reporter-plugin

Description: A plugin to customize webpack's output

Repo URL: https://github.com/misterdev/webpack-reporter-plugin

Repo Owner: misterdev

GitHub Stars: 10

graphql-schema-linter

Description: Validate GraphQL schema definitions against a set of rules

Repo URL: https://github.com/cjoudrey/graphql-schema-linter

Repo Owner: cjoudrey

GitHub Stars: 332

isolated-vm

Description: Secure & isolated JS environments for nodejs

Repo URL: https://github.com/laverdet/isolated-vm

Repo Owner: laverdet

GitHub Stars: 555

posthog

Description: 🦔 PostHog is developer-friendly, open-source product analytics.

Repo URL: https://github.com/PostHog/posthog

Repo Owner: PostHog

GitHub Stars: 1,427

react-hook-form

Description: 📋 React hooks for forms validation without the hassle.

Repo URL: https://github.com/react-hook-form/react-hook-form

Repo Owner: react-hook-form

GitHub Stars: 7,861

react-query-devtools

Description: ⚛️ Devtools for React Query

Repo URL: https://github.com/tannerlinsley/react-query-devtools

Repo Owner: tannerlinsley

GitHub Stars: 298

react-workshop-app

Description: An abstraction for all my React workshops

Repo URL: https://github.com/kentcdodds/react-workshop-app

Repo Owner: kentcdodds

GitHub Stars: 22

bad-asn-list

Description: List of bad Autonomous System Numbers (ASN) to block possible automated botnets

Repo URL: https://github.com/LorenzoSapora/bad-asn-list

Repo Owner: LorenzoSapora

GitHub Stars: 15

storybook-addon-playroom

Description: Design with Playroom inside Storybook, using each story source as a starting point

Repo URL: https://github.com/rbardini/storybook-addon-playroom

Repo Owner: rbardini

GitHub Stars: 29

gosparkpost

Description: SparkPost client library for the Go Programming Language

Repo URL: https://github.com/SparkPost/gosparkpost

Repo Owner: SparkPost

GitHub Stars: 57

csswg-drafts

Description: CSS Working Group Editor Drafts

Repo URL: https://github.com/w3c/csswg-drafts

Repo Owner: w3c

GitHub Stars: 2,146

universal-tilt.js

Description: 🎆 Parallax tilt effect library

Repo URL: https://github.com/JB1905/universal-tilt.js

Repo Owner: JB1905

GitHub Stars: 97

flutter

Description: Flutter makes it easy and fast to build beautiful mobile apps.

Repo URL: https://github.com/flutter/flutter

Repo Owner: flutter

GitHub Stars: 87,948

js-beautify

Description: Beautifier for javascript

Repo URL: https://github.com/beautify-web/js-beautify

Repo Owner: beautify-web

GitHub Stars: 6,669

formik

Description: Build forms in React, without the tears 😭

Repo URL: https://github.com/jaredpalmer/formik

Repo Owner: jaredpalmer

GitHub Stars: 20,967

Want a personalized version of these lists in your inbox every week?

Then sign up for Follow the Stars - a weekly email with the projects that the folks you follow on GitHub have starred
.

7 projects starred by top JavaScript developers that you should check out

Ryan Yost — Sun, 01 Mar 2020 21:15:50 +0000

A list of GitHub projects that were starred by multiple top JavaScript developers in the past 6 months. Read more about
the methodolgy at the end of the post.

Want a personalized version of these lists in your inbox every week?

Then sign up for Follow the Stars - a weekly email with the projects that the folks you follow on GitHub have starred
.

react-adaptive-hooks

rome

Description: An experimental JavaScript toolchain

Repo URL: https://github.com/facebookexperimental/rome

Repo Owner: facebookexperimental

GitHub Stars: 3,246

1on1-questions

Description: Mega list of 1 on 1 meeting questions compiled from a variety to sources

Repo URL: https://github.com/VGraupera/1on1-questions

Repo Owner: VGraupera

GitHub Stars: 6,518

vanillawebprojects

Description: Mini projects built with HTML5, CSS & JavaScript. No frameworks or libraries

Repo URL: https://github.com/bradtraversy/vanillawebprojects

Repo Owner: bradtraversy

GitHub Stars: 3,820

playwright

Description: Node library to automate Chromium, Firefox and WebKit with a single API

Repo URL: https://github.com/microsoft/playwright

Repo Owner: microsoft

GitHub Stars: 9,935

react-helmet

Description: A document head manager for React

Repo URL: https://github.com/nfl/react-helmet

Repo Owner: nfl

GitHub Stars: 12,604

linaria

Description: Zero-runtime CSS in JS library

Repo URL: https://github.com/callstack/linaria

Repo Owner: callstack

GitHub Stars: 4,940

Want more project recs?

I'm always late to find out about cool/amazing/game-changing/time-saving JavaScript-related projects,
so I'm experimenting with ways to uncover potentially helpful tools and resources every week.

So to get more of these project recommendation lists, join my mailing list or follow me on Twitter @ryanjyost

How the list was built

The projects below were starred by multiple experienced, influential developers, which I compiled from Googling
"JavaScript developers to follow" and looking at who I currently follow on Twitter. Their GitHub usernames are addyosmani, paulirish, thefoxis, umaar, elijahmanor, jeresig, dshaw, kentcdodds, johnpapa, darkwing, sachag, wesbos, getify, markdalgleish, chriscoyier, mdo, ry, yyx990803, Rich-Harris, sdras, emmabostian, markerikson, btholt, benlesh.

For each developer, I used GitHub's starring api to fetch their recently starred repos, limited the scope to the past 6 months, filtered out non JavaScript/TypeScript repos, then counted total stars form the user list for each repo and found the projects with multiple stars.

Here's a gist with some messy code that does it.
https://gist.github.com/ryanjyost/3e04237e11156c0784a7f101b4efc144#file-getstars-js

How to analyze your npm dependencies for better, more maintainable code

Ryan Yost — Fri, 28 Feb 2020 03:35:49 +0000

In this guide, I’m going to walk you through the things I consider when assessing the state of my npm dependencies, with
the goal of improving my software and making it more maintainable.

Why read this?

With the growing sophistication and complexity of the JavaScript ecosystem comes an increased reliance on third party
npm dependencies.

Back in the day, you used to be able to rely on vanilla JS or jQuery to handle the interactivity of your applications. But now, powerful frameworks like React, Vue, etc. and the myriad amazing libraries that work with them make it super beneficial to leverage open source solutions to our technical problems.

npm makes it easy to incorporate these third party solutions into our code - so easy, that we can take our
deps for granted and forget that they aren’t just magical black-boxes that we can stop worrying about once
implemented.

Lots can evolve - and devolve - about your dependencies that can bite your code in the ass if you aren’t paying
attention.

Why I wrote this

On multiple occasions, I’ve inherited a legacy codebase and/or been tasked with updating a codebase's dependencies.
Besides just checking how many versions behind the deps are, I do a deep dive to uncover changes or potential issues, which takes a lot of manual internet research.

To scratch my own itch and save time when assessing the current health of my dependencies, I built a simple tool that automatically gathers info about, and analyzes, the
dependencies in a package.json file. It basically does what this article walks through.

The tool is called DepChecker and I put it up at DepChecker.com.
Hope it helps folks!

Ok, let's analyze some dependencies

The process for auditing your dependencies is basically like a nested for loop...

for (let dependency of dependencies) {
  const infoAboutDependency = []

  for (let factor of factors) {
    const info = gatherInfo(dependency, factor)
    infoAboutDependency.push(info)
  }

  makeAssessment(infoAboutDependency)
}

There are a variety of useful factors that shed light on the state of your dependencies. The list we'll walk through
isn't exhaustive, but it's the one I use and is pretty thorough.

The factors to consider are...

What does the dependency do?
Is the dependency still being used in your project?
Versions behind the latest release
When was the dependency last updated?
How many weekly downloads?
How many GitHub stars?
How many open issues and pull requests?
What’s the project's license?

For each factor, I'll break down the following things...

Exactly what it is
Where to find info about it
How to assess and make sense of the info you find
Why you should care

Factor 1: What does the dependency do?

Before anything, you need to understand what your dependencies do and their role in your project. I've definitely been
guilty of seeing a dependency name I don't recognize in my package.json.

Where to find info about it

A combination of...

the package's page on npmjs.org (e.g. React)
the GitHub repository (e.g. Express)
and, if available, the project's site/documentation (e.g. Vue.js)

...should be plenty to understand its purpose.

Manually searching for each dependency can be annoying, so you can use a tool like
DepChecker, which quickly gathers the description and all of the important links for you.

How to assess the info

When starting your dependency audit, it's probably sufficient to just read the description and main points.
Later on, if other factors warrant, you can dive deeper into the documentation to better understand it and help
determine to what extent it belongs in your project.

Why you should care

Even if not for dependency management/analysis purposes, it's always best to understand what dependencies are in your
project, what they do and why your project uses them. Otherwise, you can be ignoring old, unused or potentially
dangerous dependencies that'll bring nothing but confusion and headaches to your team down the road.

Factor 2: Is the dependency still being used in your project?

It's quite common for a dependency to be installed and used in a project, then to have all uses of it
removed for various reasons but still leave the dependency in there. This is the low hanging fruit of dependency
management.

Where to find info about it

The easiest way to uncover potentially unused dependencies, ironically, is another open source npm tool called depcheck. Once installed, you can run a simple command to get a list of dependencies that it can't find references to in your project.
Perform a global text search for the dependency name and see if it's being used anywhere.
Sometimes, weird dependencies like babel plugins won't show up exactly in your project, but they are still being used. So one way to check whether it's needed is to remove it and run your app along with any tests.

How to assess the info

Corresponding to the numbered points above...

Be careful! depcheck is awesome, but it's not 100% accurate, so you should verify some other things before deleting it from your package.json.
If it's imported, is the module actually used in the code? If not, then maybe it's no longer needed.
If the tests pass and all looks good, it can be reasonably assumed that the dependency isn't needed anymore.

Why you should care

Unused dependencies just add dead kilobytes to your bundles and bloat to your project, increasing load times.
Future contributors to your codebase might think it's OK or even encouraged to use the dependency if it's already installed, which might not be ideal for your team and the code practices you try to implement.
An unused dependency just sitting in your project can introduce a compiling/transpiling bug or security vulnerability down the road.

Factor 3: Versions behind the latest release

All npm packages have a latest stable release version, whereas your package.json specifies a version of the package that it currently uses.
So your project's version can match the latest release, or be some version before it.

Here are some links for more background info...

Where to find info about it

To find the npm package's latest release version, you can go to it's offical npmjs.org page and find it in the details on the right side.

To find your project's version, go to your package.json and find the package name key in the object of dependencies or devDependencies, and the project version will be the value for that key.

With tools like npm-check and DepChecker, you can get a nice, color-coded printout of the latest version, your version AND how far behind your version is.

How to assess the info

The vast majority of npm package versioning will use the semver MAJOR.MINOR.PATCH format,
which makes it pretty easy to figure out how far behind your project version is and how much potential risk there is to upgrading.

PATCH (x.x.0) -
This denotes "backwards compatible bug fixes." So if your version is just patches behind (like the lodash example in the screenshots above), you can pretty safely just bump the version.
MINOR (x.0.x) -
This denotes new functionality that's been added "in a backwards compatible manner". Again, probably safe to upgrade so long as tests all pass.
MAJOR (0.x.x) -
This denotes "incompatible API changes" and requires diving into the changelogs, release notes, and other documentation in order to figure out the implications of doing a MAJOR version upgrade.
You'll probably need to do some manual refactoring with a major version upgrade!

As a general note, upgrading your project's dependency versions is safest with plenty of test coverage and a CI/CD pipeline.
Awesome free tools like dependabot can help automate this for you.

Why you should care

This is the factor most commonly thought of when it comes to dependency management, for good reason!
Staying up-to-date gives you access to the latest and greatest, and helps avoid getting so far behind the current version that major bugs emerge or upgrading becomes a nightmare.

Factor 4: When was the dependency last updated?

Whenever an npm package has a new version, it needs to be uploaded and published to the npm repository.
The most recent time that this occurred is called the "Last Publish". So, you can say something like "React's last publish was 2 weeks ago."

Where to find info about it

You can quickly find how long it's been since the last publish on a package's npm page.

For more details about exact dates of version releases, you'll have to check out any releases on GitHub or use the npm repository API.

How to assess the info

Generally speaking, it's a great sign if an npm package is constantly being updated and has a recent last publish date - it signifies that the contributors are actively involved and care about the dependency.

If a package hasn't been updated for a year or more, on the other hand, that could signify that the package is no longer maintained and neglected.

How to interpret the exact time since last publish can vary from package to package depending on its nature.
For example, a library of basic statistics probably doesn't need to be updated that often.
Though in the modern age of JavaScript, not updating for a while has the potential for compiling issues or incompatible versions of other dependencies.

I have some general, subjective rules-of-thumb in my head for how long it's been since the last publish...

less than 2 months - GOOD
less than 6 months - FINE
less than a year ago - WARNING
more than a year ago - DANGER

Why you should care

The time since last publish is a very strong indicator of the care and attention that an open source npm package has.

If a dependency of yours is updated very often, it generally means you can confidently continue to use it and benefit from improvements in the future.
On the other hand, a neglected package threatens your codebase and likely needs to be replaced by a comparable dependency before it causes bugs and issues for your team.

Factor 5: How many weekly downloads?

Whenever someone installs an npm package, it counts as a download. npm keeps track of these downloads and provides a weekly downloads metric for all packages.

Where to find info about it

It's easy to find on a package's npm page. You can also see a trend line there.

How to assess the info

This weekly downloads metric indicates to what extent that the dependency is being used by other developers.
Of course a download doesn't 100% mean the developer ended up keeping the dependency, but it's still a useful indicator.

Here are my subjective rules-of-thumb for weekly download counts...

more than 100,000 - GOOD
less than 100,000 - FINE
less than 10,000 - WARNING
less than 1,000 - BAD

Trends in downloads are also helpful.

If going up, it could mean that the low download count is due to the package being young but still valuable.
If going down, it could mean that the package has a superior alternative, that it's neglected, that it isn't needed anymore, etc.

In addition to the tiny trend line on the npmjs.org site, there's a cool website called npm trends where you can dive deep into npm download trends.

Why you should care

How popular am npm package is can mean a lot for its future, and therefore the future of your software.
When deciding on what npm package alternative (e.g. Angular vs. React vs. Vue) to use in your project, the download trends can be telling of what the community thinks is superior/inferior.
Downward trends can warn you about a dying dependency and allow you to preemptively remove or replace it before it negatively impacts your project.

Factor 6: How many GitHub stars?

Projects on GitHub, where the vast majority of npm package repositories are, have a star system, which is basically how people can "like" a project.

Where to find info about it

Pretty simple - just go to the GitHub repository for the npm package and the star count is on the top of the page.

How to assess the info

Obviously, the more stars a repo has, the more popular and beloved by developers it is. A high star count usually indicates that the project works well and serves the purpose that it says it does in a way that devs love.

BUT BE CAREFUL! A high star count is not enough to sign off on using/keeping a dependency, because stars accumulate over time. It's possible that the project has 20k stars, but the last star was a year ago, or it's just deprecated.

Like the weekly downloads, trends are just as important as the current total of stars. There's a couple cool websites like Star History and this one that show Github star trend lines.

Here are my subjective rules-of-thumb for GitHub stars...

more than 1,000 - GOOD
less than 1,000 - FINE
less than 300 - WARNING
less than 50 - BAD

Why you should care

Basically the same reasons as weekly downloads!

Factor 7: How many open issues and pull requests?

The beauty of open source projects is that anyone can provide feedback and contribute in the form of GitHub issues, which can become pull requests for potentially incorporating new code into the master branch and ultimately releasing an updated version.

Where to find info about it

In addition to going directly to the source on GitHub, npm provides the breakdown.

How to assess the info

The number of open issues and pull requests can indicate a few things...

How active the open source community surrounding the project is.
To what extent the project has bugs or lacks desired functionality
How active the maintainers are

If the number of open pull requests is high, that could show the community is desperate for improvements but the maintainers are asleep at the wheel or not accepting outside help - not a good sign.

The absolute number of open issues and PRs can be misleading - bigger projects with more users should naturally have more issues on GitHub, and vice versa.

So you'll want to normalize the number of open issues in your head to account for this. While far from scientific, you could think of a rough ratio of open issues and PRs to weekly downloads. The smaller the ratio, the better.

Why you should care

Lots of issues means an active user base for the dependency, which can mean it'll be maintained regularly and be safe to use long-term.
Tons of bugs in the open pull requests isn't a great sign for a piece of software you want to include in your own.
Good and bad signs can be gleaned from the current state of a dependency's open issues and pull requests - so it's valuable to pay attention!

Factor 8: What's the project license?

Open source projects like npm dependencies have a license attached to them, which dictates how the project can be used and other legal stuff.

Where to find info about it

You can find an npm package's license on its npm page.

For details of particular licenses, Google and this table-breakdown are helpful.

How to assess the info

I'm by no means a legal expert, but there's a spectrum of licenses that can be attributed to open source dependencies.

Most of them you don't have to worry about, but if an npm dependency of yours doesn't use the classic, free-reign MIT license, then it's prudent that you figure out the implications of the license for your software, especially if using in commercial software.

Here's a great article with more on that.

Why you should care

I'm sure the legal team at your company does!
If you mistakenly use an npm dependency in a manner against the license, then you expose your software and company to legal issues and other avoidable problems!

And that's it!

This is just one way to approach npm dependency management - hope it helps you with your dependencies!