DEV Community: Ash Connolly

How, and why, you should add JavaScript linting to your project. With ESLint and Gulp

Ash Connolly — Mon, 04 Mar 2024 17:36:00 +0000

Originally published here, Feb 28, 2018

Prerequisites

Node installed
A little gulp and npm knowledge is beneficial, but not required

Some people prefer to see the code first, so if you would like to download a working demo, the files can be found here (be sure to run npm i to install the dependencies).

What is linting?

Linting is the process of checking your code for potential errors. Linting tools usually allow you to specify a set of rules to check your code against. These rules can vary from general code layout, like maximum line length and code indentation, to how you declare functions.

Why lint?

Linters help you to write standardised code to ensure quality, minimise errors and increase readability. This is helpful when working in teams to ensure all developers are writing code in the same way. In day-to-day work, if developers are working with various files that have a consistent layout, it makes the code easier to read, which means developers can work faster, saving time. Linters also offer performance benefits in highlighting inefficient or unused code. Naturally we want the best user experience for our customers and keeping the code as efficient and lightweight as possible to reduce page load time is a big part of that.

ESLint

Some of the most popular JavaScript linting tools are ESLint, JSHint, JSLint and JSCS. We're going to be using ESLint. It’s very flexible, easy to use and has the best ES6 support, which will be helpful if we introduce more modern JavaScript (that will be transpiled for older browsers using https://babeljs.io/). All rules for ESLint can be found here: https://eslint.org/docs/rules/.

A great starting point – Airbnb JavaScript Style Guide

Instead of writing our own exhaustive list of JavaScript rules, we can use a ruleset defined by the developers at Airbnb, and then adjust it to suit our preferences. The Airbnb JavaScript Style Guide is well known among JavaScript developers and used by some big companies: Lonely Planet, National Geographic and Sainsburys to name a few. It’s a great place to start.

Using ESLint with Gulp

Note: Over recent years Webpack has become a more popular choice than Gulp due the increase of JavaScript applications which require a more configurable build system. However, if that flexibility isn’t needed Gulp is still great for many projects.

We could install ESLint globally and run it from the command line using the command eslint. However, in this tutorial we are going to be using ESLint in a gulp project and that means we can install ESLint, and all necessary dependencies, locally. This is beneficial for other people on the project as all dependencies are kept neatly inside the project (listed in the package.json) and won’t require any extra work or global installations.

Installing our dependencies

If you don’t yet have gulp installed, in terminal navigate to the root of your project folder and run:

npm install gulp --save-dev

Note the --save-dev will add the package to your package.json as development dependencies.

Here are the ESLint dependencies we are going to install:

eslint – the ESLint tool
gulp-eslint – the gulp plugin for ESLint
eslint-config-airbnb – the Airbnb ESLint configuration (rule set)
eslint-plugin-react – a plugin to add react-specific rules for ESLint to use
eslint-plugin-import – a plugin to add linting ES2015+ (ES6+) import/export syntax
eslint-plugin-jsx-a11y – a plugin to check accessibility of JSX elements (react)

To install all of these run (again from the root of your project folder):

npm install gulp gulp-eslint eslint-config-airbnb eslint eslint-plugin-react eslint-plugin-import eslint-plugin-jsx-a11y --save-dev

Adding an ESLint configuration file

We now need to add an ESLint configuration file, which will tell our linting process what standards and rules our code needs to meet. We could have a file named .eslintrc in the root of our user folder, which would set global default linting rules. Instead, we will have an .eslintrc file in the root of our project folder to set rules for this individual project.

To create the file, in terminal go to the root of your project and run

touch .eslintrc

This will create the file and we can add our rules to it. Note this file begins with a full stop so might not be visible in mac finder or windows explorer but should be visible in your code editor/IDE.

Open up the file and add the following:

{
  "env": {
    "es6": true,
    "browser": true,
    "node": true,
    "jquery": true
  },
  "extends": "airbnb",
  "rules": {}
}

This will set our linting up to work with ES6, the browser, node, jQuery and use Airbnb’s configuration/ruleset. We can add extra rules that will override those in the Airbnb ruleset in the rules object. For example, if you would rather indent using tabs (you reckless animal), your rules would look like:

"rules" : {
    "indent": ["error", "tab"]
}

View more rules here: https://eslint.org/docs/rules/
You can specify error, warn, or off to choose how a rule should be flagged or if it's disabled entirely.

Adding a gulp ESLint task

Now we have ESLint installed and our rules ready, we need to add our gulp task and dependencies to our gulpfile.js which will run our linting. In your gulp file you will need the following:

var gulp = require('gulp')
var eslint = require('gulp-eslint')

gulp.task('eslint', () => {
  return gulp
    .src('./exampleCode.js')
    .pipe(eslint())
    .pipe(eslint.format())
    .pipe(eslint.failAfterError())
})

Be sure to link the src to your JavaScript file, or lint all the JS files in a directory using globbing - return gulp.src(‘./folder-path/**/*.js’)

Now if we run gulp eslint from the command line it should highlight our issues. For example, if our exampleCode.js file contained:

function exampleFunction() {
  var testObject = {
    name: 'Ash Connolly',
    location: 'Sheffield',
  }
  return testObject.name + ', ' + testObject.location
}

exampleFunction()

...it would return the following errors:

~/Ash/sites/eslint-tutorial $gulp eslint
[15:37:42] Using gulpfile ~/Ash/sites/eslint-tutorial/gulpfile.js
[15:37:42] Starting 'eslint'...
[15:37:43]
/Users/Ash/Ash/sites/eslint-tutorial/exampleCode.js
  2:1   error  Expected indentation of 2 spaces but found 4    indent
  2:5   error  Unexpected var, use let or const instead        no-var
  3:1   error  Expected indentation of 4 spaces but found 8    indent
  3:9   error  Unnecessarily quoted property 'name' found      quote-props
  3:16  error  Strings must use singlequote                    quotes
  3:16  error  Missing space before value for key 'name'       key-spacing
  4:1   error  Expected indentation of 4 spaces but found 8    indent
  4:9   error  Unnecessarily quoted property 'location' found  quote-props
  4:20  error  Missing space before value for key 'location'   key-spacing
  4:20  error  Strings must use singlequote                    quotes
  4:31  error  Missing trailing comma                          comma-dangle
  5:1   error  Expected indentation of 2 spaces but found 4    indent
  6:1   error  Expected indentation of 2 spaces but found 4    indent
  6:12  error  Unexpected string concatenation                 prefer-template

✖ 14 problems (14 errors, 0 warnings)
  14 errors, 0 warnings potentially fixable with the `--fix` option.

[15:37:43] 'eslint' errored after 1.48 s
[15:37:43] ESLintError in plugin 'gulp-eslint'
Message:
    Failed with 14 errors

Now we can see parts of our code that don’t align with the rules.

⚡️ The magical fix ️️⚡️

One of the great things about ESLint is that it can fix our code for us!
To do this we need to create a new task that will both lint and fix the code.

First of all we need to install an npm module called gulp-if which allows to us to check if ESLint has fixed the file, before we update the file.

npm install gulp-if --save-dev

Now in our gulp file we need to:

Add the new gulp-if dependency
Add a new function to check if ESLint has fixed the file
And then add our new task that both lints and fixes the file.

Our entire gulp file will now look like this:

var gulp = require('gulp')
var eslint = require('gulp-eslint')
var gulpIf = require('gulp-if') // new dependency added

gulp.task('eslint', () => {
  return gulp
    .src('./exampleCode.js')
    .pipe(eslint())
    .pipe(eslint.format())
    .pipe(eslint.failAfterError())
})

// new function added to check if ESLint has run the fix
function isFixed(file) {
  return file.eslint != null && file.eslint.fixed
}

// new lint and fix task
gulp.task('eslint-fix', () => {
  return (
    gulp
      .src('./exampleCode.js')
      .pipe(
        eslint({
          fix: true,
        })
      )
      .pipe(eslint.format())
      // if running fix - replace existing file with fixed one
      .pipe(gulpIf(isFixed, gulp.dest('./')))
      .pipe(eslint.failAfterError())
  )
})

Now if we run gulp eslint-fix we should get the following:

~/Ash/sites/eslint-tutorial $gulp eslint-fix
[15:38:52] Using gulpfile ~/Ash/sites/eslint-tutorial/gulpfile.js
[15:38:52] Starting 'eslint-fix'...
[15:38:54] Finished 'eslint-fix' after 1.51 s

Now we can see that all of our previous problems have been removed and the contents or our exampleCode.js file has been updated in various ways.

Before:

function exampleFunction() {
  var testObject = {
    name: 'Ash Connolly',
    location: 'Sheffield',
  }
  return testObject.name + ', ' + testObject.location
}

exampleFunction()

After:

function exampleFunction() {
  const testObject = {
    name: 'Ash Connolly',
    location: 'Sheffield',
  }
  return `${testObject.name}, ${testObject.location}`
}

exampleFunction()

Changes made:

All indentation has been updated
Var changed to ES6 const
Unnecessary quoting of object property removed
Double quotes changed to single in object values
Space before object values added
Added trailing comma for last object property
Return string has been changed to an ES6* template literal.

And that's it! All our linting is working and it can fix our code for us! 😀
When running the fix you should be confident that you understand the issues and changes made after running the fix to ensure that your JS behaves as expected.

* Please note the last change involves converting a JavaScript string to an ES6 JavaScript template literal, which as an ES6 feature, is not supported in all browsers. To enable use of ES6 JavaScript in older browsers you will need to transpile it using https://babeljs.io/.

If you would like to download a working demo containing all the code in this tutorial please click here (be sure to run npm i to install the dependencies).

Advanced example

If you would like to see a more advanced gulp task where we can pass options via the command line, we can use the advanced example below (note this requires you to install a new dependency by running npm i yargs --save-dev):

var gulp = require('gulp')
var eslint = require('gulp-eslint')
var gulpIf = require('gulp-if')
var argv = require('yargs').argv

gulp.task('eslint', () => {
  var target = argv.file ? argv.file : './exampleCode.js'
  var fixCode = argv.fix ? true : false

  return gulp
    .src(target, { base: './' })
    .pipe(
      eslint({
        fix: fixCode,
      })
    )
    .pipe(eslint.format())
    .pipe(gulpIf(isFixed, gulp.dest('./')))
    .pipe(eslint.failAfterError())
})

We can now pass ESLint a specific file to lint, if we don’t it will use the default target in the gulp task, currently set to ./exampleCode.js. We can also set a flag to fix the file using --fix.

Here is a list of example commands you could pass to the eslint gulp task:

gulp eslint                                      // lint default target(s)
gulp eslint --fix                                // lint + fix all default target(s)
gulp eslint --file ./folder/filename.js          // lint supplied file
gulp eslint --file ./folder/filename.js --fix    // lint + fix supplied file

Enjoy, and happy linting! 😀

If you like React, Next.js or front end development in general, feel free to follow and say hi on Twitter @AshConnolly_! 👋 🙂

The benefits of ☠️ skeleton screens / content placeholders and how to make them

Ash Connolly — Mon, 27 Sep 2021 14:18:33 +0000

What are they?

Skeleton screens are a way of communicating to the user that content is loading. They go by many names: content placeholders, interface previews, skeleton patterns, to name a few. It’s likely you’ll have seen them before, as they’re used by some big companies like Slack, Facebook and Medium.

Facebook skeleton screen (credit to css-tricks):

Slack skeleton screen:

Medium skeleton screen:

They aren’t exactly a new thing, Luke Wroblewski introduced the concept during the development of his Polar app (now acquired by Google) all the way back in 2013. They're now seeing more widespread adoption and for good reason.

Why use them?

When content is loading, either on page load or after an interaction, it's important to communicate this to the user in an appropriate way. Skeleton screens give us the opportunity to indicate the type of content that's loading, which helps increase the perceived performance of our interface:

"Perceived performance is a measure of how fast something feels to the user. The idea is that users are more patient and will think of a system as faster if they know what's going on and can anticipate content before it's actually there. It's a lot about managing expectations and keeping the user informed."

— Max Böck

It also gives a much smoother transition when the skeleton screen is removed and the content is shown.

What about good old progress indicators?
We could use a progress indicator (like a spinner) to show this. However, after years of use, users are all too familiar and frustrated with progress indicators:

"With the introduction of these progress indicators, we had made people watch the clock. As a result, time went slower and so did our app."

— Luke Wroblewski,

It's also quite a jarring experience to see a small progress indicator replaced by a large chunk of content.

Creating the skeleton screens

When animating web elements, it's important to prioritise performance. The last thing you want is for your skeleton screens to cause unnecessary load on your device, slowing down your webpage and creating a janky experience for the user.

I had three simple requirements when creating them to ensure high performance and flexibility in use:

Have as few animating elements as possible
Only use GPU-based animations, like translate
Use modifiers classes to affect the height and repetition of elements so that these skeleton screens are customisable

To have as few animating elements as possible, there’s a small bit of visual trickery going on. We only have one element animating, then we overlay white lines to make it appear as if there are many elements being animated. In the example below the overlay can be toggled on and off:

To reduce the markup, the overlays are created using linear gradients. This ensures that they will repeat endlessly, regardless of the height of the component. This means if we want a skeleton screen to have more repetition, for example showing eight lines instead of four, we can simply change its height using a modifier class:

This makes the components scalable and flexible without the need for extra, repetitive DOM elements.

More skeleton screens for more scenarios

As mentioned earlier, skeleton screens should indicate the type of content that's loading. This means we’ll likely need several skeleton screens to represent the various types of content:

I won’t dive into the code, but it can all be seen in the codepen above. It utilises several SCSS variables and mixins to make customising it as easy as possible.

A final performance check

It’s a good idea to check the skeleton screens are as performant as can be to ensure the best user experience. Thankfully Chrome Developer Tools makes this ver easy with its frame-rate meter found in Render Settings (click here for instructions).

As you can see, our frame rate is a fairly consistent 60fps. This means our skeleton screens are performing well and not negatively impacting the page.

And there we have it. We now have in place lightweight, performant, and flexible skeleton screens to help create a better user experience.

If you like React, Next.js and front end development, feel free to follow me and say hi on twitter.com/AshConnolly_! 👋 😃

Stunning cover photo by Lukasz Szmigiel on Unsplash!

Prevent "window is not defined" Errors With a useClientSide() Custom Hook

Ash Connolly — Mon, 27 Sep 2021 11:09:41 +0000

TLDR:

There is no window object on the server - trying to access the window object will thrown an error in server side rendered code, and in Node.js based development environments
You can access window in a useEffect hook, as uesEffect only runs on the client
We want to avoid having to repeat this useEffect logic in every component that needs to access window
Instead we can move this logic into a custom react hook to keep everything super tidy! 🎉

The finished useClientSide() hook:

const useClientSide = func => {
  const [value, setValue] = useState(null)
  useEffect(() => {
    setValue(func())
  }, [func])
  return value
}

const getUserAgent = () => window.navigator.userAgent

export default function Example() {
  const userAgent = useClientSide(getUserAgent)
  return <>{userAgent && <p>{userAgent}</p>}</>
}

Heres a stackblitz⚡ Next.js demo.

The Problem

When trying to access window with react frameworks like Next.js you might run into issues when trying to access the window object and see the following error:

This is because somewhere in your app window is trying to be accessed from the server, where it does not exist.

In Next.js this could be because we're trying to access window on a page that uses getServerSideProps, which makes the page a server side rendered (SSR).

You might think:

"But my app is static, with no server side rendering, why am I getting Server errors??"

Most development environments are created by running a local Node.js server (Next.js does this). And as Node.js runs on the server, there is no window object

Example Problem: Device Detection

Say if you had a button, and on a touch device you want it to say "Tap here", otherwise it would say "Click here", you could check the window object for navigator.userAgent.

This would tell us what device type they're on, like Android or IOS, and we could infer if it's a touch device. There are other ways to check touch devices, but for the purposes of this tutorial, we'll do it this way.

You could approach it like this for client side rendered apps:

const isTouchDevice = () => {
  const ua = window.navigator.userAgent
  if (ua.match(/Android|webOS|iPhone|iPad|iPod|BlackBerry|BB10|PlayBook|IEMobile|Opera Mini/i)) {
    return true
  }
  return false
}

export default function Example() {
  const isTouch = isTouchDevice()
  return <button>{isTouch ? 'Tap here!' : 'Click here!'}</button>
}

Note: I won't show the code for isTouchDevice() again, just to keep the code examples clearer. Just remember it returns true or false! :)

Here we are getting the window.navigator.userAgent and then passing it into our function and checking if it contains any identifiers for touch devices, if it does return true, otherwise return false.

However, this code will cause the window is not defined error, as our local dev environment is running on a server, where there is no window object!

A Common, But Not Ideal Solution 🙅‍♂️

We could check if window is not defined by adding this line at the top of any function that tries to access window:

  if (typeof window === 'undefined') return

Note you cannot do window === undefined as this assume would window is declared, but has no value. When actually, window hasn't been declared at all. This is the difference between:

undefined: a variable that is declared but not initialised or defined (aka not given a value)
not defined: a variable that has not been declared at all

Using typeof window === 'undefined' is far from ideal and can cause rendering issues as explained in this brilliant in-depth article by @joshwcomeau: The Perils Of Rehydration.

The Solution: Only Reference Window On The Client 👍

We can do this by running our isTouchDevice() function inside a useEffect, which only runs on the client when the component mounts.

We can also store the return value of isTouchDevice() in state by using useState. Storing it in state means that it's value is preserved during re-renders.

Here's a working example:

import { useEffect, useState } from 'react'

const isTouchDevice = () => {} // returns true or false, see code above

export default function Example() {
  const [isTouch, setisTouch] = useState(null)

  useEffect(() => {
    setisTouch(isTouchDevice())
  }, [])

  return <button>{isTouch ? 'Tap here!' : 'Click here!'}</button>
}

Once the component mounts (which only happens on the client) the function is run and the state of isTouch is updated to a true or false value, which causes our button to show the correct messaging.

🤔 But having to do this every time you want to use the isTouchDevice function is really a hassle and will lead to lots of needless repetition of useEffect().

What would be much neater is a custom react hook that obfuscates all of this logic, allowing us to do something like this:

export default function Example() {
  const isTouch = useIsTouchDevice()
  return <p>{isTouch ? 'Tap here!' : 'Click here!'}</p>
}

That would help make things easier, but something else would be better...

A Step Further: Making a `useClientSide()` Hook! 🔥

What would be even better than a useIsTouchDevice() hook? A flexible, generalized custom hook that could take any function as an argument, and only run that function on the client side: a useClientSide() hook! 😃

Example:

const useClientSide = func => {
  const [value, setValue] = useState(null)
  useEffect(() => {
    setValue(func())
  }, [func])
  return value
}

const getUserAgent = () => window.navigator.userAgent

export default function Example() {
  const userAgent = useClientSide(getUserAgent)
  return <>{userAgent && <p>{userAgent}</p>}</>
}

What this custom hook is doing:

taking a function as an argument
calling that function in a useEffect hook (which is only done on the client)
saving what is returned by that function to the local state of the useClientSide() hook
then returning that local state value

Now let's use it with our isTouchDevice() function:

import { useEffect, useState } from 'react'

const isTouchDevice = () => {
  const ua = window.navigator.userAgent
  if (ua.match(/Android|webOS|iPhone|iPad|iPod|BlackBerry|BB10|PlayBook|IEMobile|Opera Mini/i)) {
    return true
  }
  return false
}

const useClientSide = func => {
  const [value, setValue] = useState(null)
  useEffect(() => {
    setValue(func())
  }, [func])
  return value
}

export default function Example() {
  const isTouch = useClientSide(isTouchDevice)
  return <p>{isTouch ? 'Tap here!' : 'Click here!'}</p>
}

Heres a stackblitz⚡ Next.js demo.

If you want to check the isTouch is working as expected, just simulate a mobile device using your browser's dev tools. Like device mode in chrome.

Done!

There we go! All working! We have a useful, reusable custom hook that allows use to run any client specific code easily! 😃 🎉

I built this hook while building episoderatings.com (a way to view episode ratings in a graph), to help me easily detect touch devices and display specific messaging!

If you like React, Next.js and front end development, feel free to follow me and say hi on twitter.com/AshConnolly_! 👋 🙂

Stunning cover photo by Spencer Watson on Unsplash!

How To Quickly Add Cypress To Your Next.js App

Ash Connolly — Mon, 31 May 2021 11:14:32 +0000

Pssst... you might also like this guide on adding Jest to your Next.js App. Combined with Cypress, it's a great setup! 😃

How To Quickly Add Jest To Your Next.js App

Ash Connolly ・ May 30 '21

#nextjs #react #beginners #javascript

Why use Cypress for end to end / integration testing?

Writing Cypress tests are easy and feel intuitive
Good developer experience with quick setup
The tests resemble how apps are used, not how they are implemented, which means they don't need changing even if you refactor your whole app!

Adding Cypress

Install the dependencies

yarn: yarn add cypress start-server-and-test --dev
npm: npm install cypress start-server-and-test --save-dev

The start-server-and-test will allow us to run our app locally before starting Cypress.

Now we need to open Cypress for the first time:

yarn: yarn run cypress open
npm: npx cypress open

This will add a bunch of folders to the root of your app:

cypress/fixtures → these are our mock server response
cypress/integration → these our UI tests
cypress/plugins → these are, you guessed it, cypress plugins!
cypress/supports → these are reusable functions to use in our tests

This will also have added a bunch of helpful example tests in cypress/integration/examples too!

Adding scripts

Now we need to add some scripts to our package.json so we can run cypress.

What we could do open two terminal windows...

In one we would run our app locally using yarn dev or yarn start (depending on your setup).
And in the other terminal run the cypress tests against our local app.

But that's not ideal. Instead we want to be able to run a single command that will do both of these for us. This will make running the tests in a release pipeline (like jenkins, circle CI, or github actions etc) easier to do.

NOTE: I use yarn dev to run my app locally (as it's a next.js app) on port 3000. if you use a different command (like start) or a different port, be sure to change it in the scrips below.

Add the following scripts (the ones starting with cy) to your package.json:

"scripts": {
    "dev": "next dev",
    ...
    "cy:open-only": "cypress open",
    "cy:run-only": "cypress run",
    "cy:open": "start-server-and-test dev 3000 cy:open-only",
    "cy:run": "start-server-and-test dev 3000 cy:run-only"
  },

Remember, the start-server-and-test command will allow us to run our app locally before starting Cypress.

cy:open-only will open the cypress GUI
cy:run-only will run cypress tests
cy:open will run dev to run our app locally, and then run cy:open-only to open the cypress GUI.
cy:run will run dev to run our app locally, and then run cy:run-only to run the cypress tests in the terminal.

The first two commands on their own will not work unless your app is running. Which is why we have the last two commands, which will run our app locally, then run the tests, without the need to run our app in a separate terminal.

Adding our first test

Add a test file to ./cypress/integration/ called app.spec.js

context('App', () => {
    it('should load our app and show content', () => {
      cy.visit('<http://localhost:3000>')
      cy.contains('Welcome to Next.js!')
    })
  })

Be sure to update the cy.contains to reference some text found on your homepage. I'm doing this in a brand new Next.js app, so I'm checking for Welcome to Next.js!.

Now if we run:

yarn: yarn cy:run
npm: npm run cy:run

We will see our tests running in the terminal!:

We can also open the Cypress GUI and see our tests run in a browser: Then we'll open cypress

yarn: yarn cy:open
npm: npm run cy:open

And we should see our Cypress testing window, showing all available tests:

Note: I have collapsed the folder called examples.

Click the app.spec.js and it will pop open a browser, navigate to your app, and run our tests against it!

Done!

And that's it! We have added Cypress to our Next.js app! 🎉 😃

Now we can write end-to-end tests for all of our user journeys! For further learning on Cypress, I highly recommend the "Cypress in a Nutshell" video by Amir Rustamzadeh (Head of Developer Experience at Cypress). It's a very practical and concise watch!

If you're interested in hearing more tips about React, Next.js, and JavaScript, feel free to follow me on twitter! 😃

Stunning cover photo by Matthew on Unsplash!

How To Quickly Add Jest To Your Next.js App

Ash Connolly — Sun, 30 May 2021 18:22:05 +0000

Pssst.. you might also like this guide on adding Cypress to your Next.js App. Combined with Jest, it's a great setup!

How To Quickly Add Cypress To Your Next.js App (deprecated)

Ash Connolly ・ May 30 '21

#nextjs #javascript #beginners #react

Adding Jest

Add the jest dependency:

yarn: yarn add jest --dev
npm: npm install jest --save-dev

Add a jest script to your package.json so that we can run jest against our test files:

"scripts": {
    "jest": "jest"
  }

Add a test file anywhere in your app. For now lets call it example.test.js :

const sum = (a, b) => a + b

describe('sum()', () => {
  it('should return 5 if given 2 and 3 ', () => {
    expect(sum(2, 3)).toBe(5)
  })
})

Now if we run yarn jest or npm run jest we'll see the test is found, it runs, and passes! ✅

Jest with Cypress

If you're using Cypress, we need to add our own jest.config.js file to tell Cypress to ignore our cypress tests. Otherwise Jest will pick them up and try to run jest on the files and cause an error. This is because Jest is set up to run tests on files that end in spec.js or test.js and Cypress tests end in spec.js.

module.exports = {
  // An array of regexp pattern strings, matched against all module paths before considered 'visible' to the module loader
  modulePathIgnorePatterns: ['./cypress'],
}

You can also setup a jest config file using npx jest --init

Done!

And that's it! We have added Jest to our Next.js app! 🎉 😃

Now we can unit test all of our JS logic / helper functions! For more details on how to write tests, be sure to check the Jest Docs.

If you're interested in hearing more tips about React, Next.js, and JavaScript, feel free to follow me on twitter!😃

Epic cover photo by Ken Smith on Unsplash!

DEV Community: Ash Connolly

How, and why, you should add JavaScript linting to your project. With ESLint and Gulp

Prerequisites

What is linting?

Why lint?

ESLint

A great starting point – Airbnb JavaScript Style Guide

Using ESLint with Gulp

Installing our dependencies

Adding an ESLint configuration file

Adding a gulp ESLint task

⚡️ The magical fix ️️⚡️

Advanced example

The benefits of ☠️ skeleton screens / content placeholders and how to make them

What are they?

Why use them?

Creating the skeleton screens

More skeleton screens for more scenarios

A final performance check

Prevent "window is not defined" Errors With a useClientSide() Custom Hook

The Problem

Example Problem: Device Detection

A Common, But Not Ideal Solution 🙅‍♂️

The Solution: Only Reference Window On The Client 👍

A Step Further: Making a useClientSide() Hook! 🔥

Done!

How To Quickly Add Cypress To Your Next.js App

How To Quickly Add Jest To Your Next.js App

Ash Connolly ・ May 30 '21

Why use Cypress for end to end / integration testing?

Adding Cypress

Install the dependencies

Adding scripts

Adding our first test

Done!

How To Quickly Add Jest To Your Next.js App

How To Quickly Add Cypress To Your Next.js App (deprecated)

Ash Connolly ・ May 30 '21

Adding Jest

Jest with Cypress

Done!

A Step Further: Making a `useClientSide()` Hook! 🔥