
[Vercel Serverless Functions](https://vercel.com/docs/concepts/functions) are an an indispensable tool for building apps on Vercel, and the only way to test them locally is with the CLI.

`vercel dev` works perfectly with Next.js and create-react-app, but recently I came across a strange bug when using `vercel dev` with my vite application.

Let's walk through the bug and then walkthrough the solution.

## The Bug

Imagine you have a vite app with client-side routing and a few routes deployed to Vercel, [like this one](https://routing-vite-vercel-serverless-miv42i8n3-tone-row.vercel.app/).

Navigating with the links works great, but if you try to load a page other than the index Vercel gets confused. Try going directly to the [about page](https://routing-vite-vercel-serverless-miv42i8n3-tone-row.vercel.app/about).

There's no file at `/about.html`, so instead we see an error from vercel.

<img
  src="https://res.cloudinary.com/tone-row/image/upload/v1652373156/tone-row-2021/cunqqnyx6aqsasabacqu.png"
  width="443"
  alt="Vercel error"
/>

This is a common stumbling block for client-side routing. To fix it, we need to make sure any requests to our domain are redirected to `/index.html`. That way our application will load, which in turn loads our router, which in turn loads the correct page.

To do this on vercel we use a `vercel.json` file with the following contents:

```json
{
  "rewrites": [{ "source": "/(.*)", "destination": "/index.html" }]
}
```

If we deploy this, we can now load our pages directly. [Try it out!](https://routing-vite-vercel-serverless-kiocsreua-tone-row.vercel.app/about)

## Vercel Dev

Now, instead of running your app locally with `yarn dev`, try running `vercel dev`.

You'll need to have have the [Vercel CLI](https://vercel.com/docs/cli) installed. The first time you run `vercel dev` you'll need to connect it to your deployment.

When you see something like this in your console you'll know it's running as intended.

<img
  src="https://res.cloudinary.com/tone-row/image/upload/v1652376162/tone-row-2021/ie3qr750vh5aknker3dz.png"
  width="359"
  alt="Vercel dev running vite"
/>

However, when you visit the address on localhost, you'll see our app is broken! 😱

## What's the problem?

Using `vercel.json` to fix routing on our deploys breaks our routing locally. I reached out to Vercel about this problem. They confirmed it's an issue and they also said it wasn't on their roadmap to fix it.

But I love vite too much to give up!

## The Quick Solution

Rename `vercel.json` to `_vercel.json` then run `vercel dev` again and everything will be working.

For about a week I attempted to remember to keep `vercel.json` renamed locally– but to avoid committing that change so as not to break routing.

Lo and behold... I broke my app a few times. So then the question became: how can I prevent myself from accidentally committing the `vercel.json → _vercel.json` change?

## Git Hooks: The Sustainable Solution

If you’re not familiar with git hooks, they let you run code whenever you run git commands. They have names like “pre-commit” (i.e., before the code is committed) or “post-receive”, and they live inside your hidden `.git` directory along with all the other git guts.

My idea was to:

- Prevent `_vercel.json` from being committed using `.gitignore`
- Prevent the deletion of `vercel.json` from being committed by using a `pre-commit` hook:

The git ignore part is easy. We just add `_vercel.json` to the `.gitignore` file.

```bash
# Don't commit unused routing file
_vercel.json
```

For the pre-commit hook, we can add a small script in the root of our project called `prevent-delete.sh` (or whatever you like) with the following contents:

```bash
# Prevent deletion of vercel.json from being committed

#D       vercel.json
REGEXP="^D[[:space:]]+vercel.json$"

if git diff --cached --name-status | grep -qE $REGEXP; then
  git reset -- vercel.json
  exit 0
fi
```

This script looks for a line that starts with `D` and then checks if it contains `vercel.json`. If it does, it resets the file to its original state, which in our case is deleted but not staged.

We need to make sure our script is executable by git so we run:

```bash
chmod +x prevent-delete.sh
```

Then we create a symlink from the git hooks directory to our script. Note– Don't do this if your app is already setup with `husky`; see below.

```bash
ln -s ../../prevent-delete.sh .git/hooks/pre-commit
```

Now if we add all our changes with `git add -A` and run `git status` we can see that `_vercel.json` is being ignored, and the delete of `vercel.json` is staged to be committed.

<img
  src="https://res.cloudinary.com/tone-row/image/upload/v1652377996/tone-row-2021/wrqprr2uifzjjzwsr23w.png"
  width="377"
  alt="Git status after add"
/>

But, when we run `git commit -m "Add prevent-delete.sh"` we get the following output:

<img
  src="https://res.cloudinary.com/tone-row/image/upload/v1652378121/tone-row-2021/oqaxkibbr4ft2qh12g89.png"
  width="356"
  alt="Git commit output"
/>

Success! If you check `git status` again you'll see that the deletion of vercel.json wasn't committed. We can safely push this code knowing the deployment vercel creates won't have broken routing because of a missing `vercel.json` file.

## If you are using husky

Many apps use [husky](https://github.com/typicode/husky) to automatically run git hooks. This is the recommended pathway for things like linting staged files.

If you're using husky, instead of symlinking the script, just run

```bash
npx husky add .husky/pre-commit "./prevent-delete.sh"
```

This will add the script to the `pre-commit` hook.

## In conclusion

That's it! Now you can `git add -A` and `git commit` to your heart's content without being worried about breaking your application. 🎉🎉🎉

Thanks for reading! If you have questions reach out to me on [Twitter](https://twitter.com/tone_row_)


Getting vercel dev to work with vite locally so serverless functions and client-side routing play nicely.

Vite, Vercel Serverless, and Client-Side Routing


The year was 2018. Assert Conference was held in the La Orilla Del Rio Ballroom in San Antonio, Texas. During one of the presentations, Ex-Paypal-Employee-Turned-Remix-Evangelist Kent C. Dodds presents a "Testing Trophy"; a spin off from a tweet by Guillermo Rauch.

The gist was simple: integration tests.

<img
  src="https://res.cloudinary.com/tone-row/image/upload/v1625165663/tone-row-2021/kcd-testing-trophy.png"
  alt="Kent Dodds Testing Trophy"
  width="443"
  height="291"
/>

> ["It's so much faster to run a node process than to pull up a full browser and run that... hopefully that will get faster with our tools"](https://www.youtube.com/watch?v=Fha2bVoC8SE&t=796s)

_Hopefully..._

Fast forward to 2021. With deploy previews à la Netlify and Vercel, Github Actions, and Playwright we may be one step closer to E2E tests that are just as cheap as integration tests.

Let's assume we're working on a website or app hosted on netlify with deploy previews on pull-requests. [Here is an example application](https://github.com/tone-row/easy-e2e), forged in the flames of create-react-app, that stores some text in local storage.

<img
  src="https://res.cloudinary.com/tone-row/image/upload/c_crop,g_west,w_472/v1625166486/tone-row-2021/demo-app-gif.gif"
  alt="Demo App - user enters text and it's displayed"
  width="473"
  height="246"
/>

When I make PR's I end up with a fancy netlify preview like so:

<img
  src="https://res.cloudinary.com/tone-row/image/upload/v1625167916/tone-row-2021/netlify%20deploy%20preview.png"
  alt="Example netlify deploy preview"
  width="1254"
  height="570"
/>

## Goal

- grab the netlify preview url
- run some end-to-end tests with playwright
- sleep better at night!

## Step 1

We'll use a globally installed version of `playwright` so the only package we need to add to our repo is the test runner.

```shell
yarn add -D @playwright/test
```

## Step 2

Add an `e2e` npm script to run it.

```json
"e2e": "npx playwright test --browser=all e2e"
```

This is going to run any tests in our `e2e` folder in Chrome, Firefox, Safari.

## Step 3

Create the folder we referenced above and add one test file.

```bash
mkdir e2e && touch e2e/app.spec.ts
```

## Step 4

Let's test that our page has the correct title:

```tsx
// app.spec.ts
import { test as base, expect } from "@playwright/test";

const test = base.extend<{ url: string }>({
  url: process.env.E2E_START_URL ?? "http://localhost:3000",
});

const { describe, beforeEach } = test;

describe("App", () => {
  beforeEach(async ({ page, url }) => {
    await page.goto(url as string);
  });

  test("Correct Page Title", async ({ page }) => {
    const title = await page.title();

    // Replace this with your app's page title
    //                 ⤵
    expect(title).toBe("Save Some Text");
  });
});
```

We use `base.extend` to pass fixtures (in our case `url`) to each of our test runs.

## Step 5 – Test Locally

In one shell, start your app (`yarn start` for create-react-app).

In another shell, try `yarn e2e`. You may need to install some playwright dependencies the first time you run it, but you should see 3 tests run and pass.

For a little added spice, try `yarn e2e --headed`. This will open the browser window and give you some good insight into what the test runner does behind the scenes.

## Step 6 – Continuous Integration with Github Actions

If you don't already have any github actions running, create the directory `.github/workflows` in the root of your repo. Then add the following code a file called `e2e.yml`

```yaml
# .github/workflows/e2e.yml
name: E2E Tests

on: [pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: Setup Playwright
        run: npx playwright install-deps
      - name: Install
        run: yarn install
      - name: Waiting for 200 from the Netlify Preview
        uses: jakepartusch/wait-for-netlify-action@v1.2
        id: waitFor200
        with:
          site_name: "reverent-joliot-43ca55" # <-- replace with your site url
      - name: Run E2E Tests on Netlify URL
        run: E2E_START_URL="${{ steps.waitFor200.outputs.url }}" yarn e2e
```

If you haven't seen a github action before, this yaml file is saying, "On pull requests, run each of these steps in order". You can learn more about writing github actions [here](https://docs.github.com/en/actions).

Individual steps can actually reference other github actions. The magic ingredient of our e2e tests is an action created by [Jake Partusch](https://twitter.com/JakePartusch), which waits for and returns the netlify deploy preview url. Afterwards we store the url on an environment variable and run our end-to-end script.

Don't forget to change the `site_name` to your netlify site's ID. You can
find that by logging into netlify and looking at your project.

## Bada Bing Bada Boom

That's it! You should now be able to open up a pull requests on your app, and GitHub will run end-to-end tests on the netlify deploy preview url.

---

## Writing Better Tests

Obviously testing the page's title isn't going to give you much confidence in your app. Here are a few more tests I added to the demo app, to give you an idea of what playwright tests look like.

```ts
import { test as base, expect } from "@playwright/test";

type Fixtures = { url: string };

const test = base.extend<Fixtures>({
  url: process.env.E2E_START_URL ?? "http://localhost:3000",
});

const { describe, beforeEach } = test;

describe("App", () => {
  beforeEach(async ({ page, url }) => {
    await page.goto(url as string);
  });

  test("Correct Page Title", async ({ page }) => {
    const title = await page.title();
    expect(title).toBe("Save Some Text");
  });

  test("Displays user input", async ({ page }) => {
    await page.click("input");
    // Fill input
    await page.fill("input", "This is working");

    const display = await page.innerText("span.display");

    expect(display).toEqual("This is working");
  });

  test("Retains text on refresh", async ({ page }) => {
    await page.click("input");
    // Fill input
    await page.fill("input", "This is working");

    let display = await page.innerText("span.display");

    expect(display).toEqual("This is working");

    await page.reload();

    display = await page.innerText("span.display");

    expect(display).toEqual("This is working");
  });
});
```

One of the amazing features of playwright is the ability to generate code for your tests via the [codegen CLI command](https://playwright.dev/docs/cli#generate-code). You'll definitely want to have a look at that.

This tutorial was meant to be as bare-bones as possible, but if you think I left something important out please let me know on twitter ([@tone_row\_](https://twitter.com/tone_row_)) or for typos make a PR on [this article's source code](https://github.com/tone-row/tone-row.com/blob/main/content/e2e-ci-testing-netlify-playwright-github-actions/index.mdx).

Thanks for reading!


E2E continuous integration testing might be closer than you think! 😃

E2E Testing in Minutes with Playwright and Github Actions


I’m **really** proud of what [TRACTOR Food & Farms](/partnerships/tractor-food-and-farms) and Tone Row built together.

TRACTOR Executive Director [Dru Zucchino](https://tractorfoodandfarms.com/about-us/staff/) and I have been collaborating on creative projects since we were 14 years old. Now in our early thirties, we found an opportunity to collaborate on something- equally as creative- but that will help improve food ecosystems in Western North Carolina 🤯

I just patched up what I’m sure won’t be the last bug to creep into the machine, and while doing so I noticed that some of the food pantries had already begun entering the foods that work best for the people they serve. I immediately had a big grin on my face. This thing might actually work!

---

I'm really grateful that Dru conceived of and was willing to explore this app idea with me, and that TRACTOR was willing to invest the time and trust in Tone Row to design and build it.

It has already been an amazing learning experience, and I know there's only more to learn as it heads into production. I can't wait to get feedback from TRACTOR and the food pantries.

This is an awesome first partnership and I'm excited to see where it leads!

<div style={{ textAlign: "center" }}>
  [Read more about how the app works here](/partnerships/tractor-food-and-farms)
</div>


Our first non-profit partnership app is headed into production

Launching Healthy Harvest


Howdy!

Person here 👋

Been building websites since 2011. Been React'n since 2017 or so.

I want to make cool tools for people to use, like [flowchart.fun](https://flowchart.fun), and I want to make apps that help people, like the one I'm working on with [TRACTOR Food & Farms](/partnerships/tractor-food-and-farms).

Tone Row is an experiment in putting both of those pursuits under one roof.

This blog is a document of that experiment.

Thanks for visiting!


Tools for Creativity & Productivity

Non Profit Partnerships

Blog

Connect