Cannot have an _error.tsx file without a 404.tsx file #12256

eiskalteschatten · 2020-04-27T19:23:38Z

Bug report

Describe the bug

It isn't possible to have an _error.tsx file in the /pages folder without also having a 404.tsx file. When running next dev, it works fine, but as soon as you run next build, the following error appears:

Automatically optimizing pages ...
Error occurred prerendering page "/404". Read more: https://err.sh/next.js/prerender-error:
Error: Error for page /_error: pages with `getServerSideProps` can not be exported. See more info here: https://err.sh/next.js/gss-export

According to the official Next.js Blog, it should not be a problem to have a _error.tsx without a 404.tsx: https://nextjs.org/blog/next-9-3#automatic-static-optimization-for-404

The reason I do not want a static 404 page is so that I can catch routes with a trailing slash and redirect accordingly to the route without a trailing slash. This must be done on the server.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

Create an _error.tsx file with a getServerSideProps() function.
Run next build.

Expected behavior

The error message says that it is trying to export the _error.tsx file even though it obviously shouldn't be. The application should still build. As soon as I add a 404.tsx file or remove the _error.tsx file, it builds without a problem.

System information

OS: macOS and Alpine Linux (Docker)
Version of Next.js: 9.3
Version of Node.js: 13.13.0 and 14.0.0

Additional context

Just in case it might be of any use, here is the code from my _error.tsx file:

import React, { useEffect } from 'react';
import { GetServerSideProps } from 'next';
import Head from 'next/head';
import Router from 'next/router';

import { makeStyles, createStyles } from '@material-ui/core/styles';
import Container from '@material-ui/core/Container';

import useStandardHeaderTags from '../lib/useStandardHeaderTags';
import TitleElement from '../components/TitleElement';

const useStyles = makeStyles(() =>
  createStyles({
    root: {
      textAlign: 'center'
    }
  })
);

interface Props {
  statusCode: number;
}

const Error: React.FC<Props> = ({ statusCode }) => {
  const classes = useStyles();
  const title = statusCode === 404 ? '404' : 'Error';

  return (
    <>
      <Head>
        {useStandardHeaderTags(title)}
      </Head>
      <Container className={classes.root}>
        <TitleElement text={title} />

        {statusCode === 404
          ? 'The page you are looking for could not be found.'
          : 'An error occurred.'}
      </Container>
    </>
  );
};

export const getServerSideProps: GetServerSideProps = async ({ res, req }) => {
  const statusCode = res ? res.statusCode : 404;

  if (statusCode === 404) {
    if (req.url.match(/\/$/)) {
      const withoutTrailingSlash = req.url.substr(0, req.url.length - 1);
      if (res) {
        res.writeHead(303, {
          Location: withoutTrailingSlash
        });
        res.end();
      }
      else {
        Router.push(withoutTrailingSlash);
      }
    }
  }

  return {
    props: {
      statusCode
    }
  };
};

export default Error;

The text was updated successfully, but these errors were encountered:

timneutkens · 2020-04-28T08:36:47Z

Same as #12246

timneutkens · 2020-04-28T08:37:30Z

Replied here: #11945 (reply in thread)

timneutkens · 2020-04-28T08:40:17Z

The reason I do not want a static 404 page is so that I can catch routes with a trailing slash and redirect accordingly to the route without a trailing slash. This must be done on the server.

What you're looking for seems to be #9081

pages/_error can't use getServerSideProps on purpose as explained in #11945 (reply in thread). pages/404.js can't use getServerSideProps on purpose too as it massively increases server load without a good reason, eg all 404 routes would server-render on-demand with the code that you wrote.

What we can do is improve the error message / documentation around it.

eiskalteschatten · 2020-04-28T09:13:20Z

Thank you for the replies! What isn’t clear to me though is whether the redirects feature is already available in the latest version of Next.js as it was still marked as open. Also, is it possible to create a redirect with a regex-based src key so that I can redirect all routes with a trailing slash?

This issue is unfortunately holding up the launch our website...

eiskalteschatten · 2020-04-28T13:51:18Z

I was, however, able to solve it by changing the getServierSideProps function to

Error.getInitialProps = ({ res, req, err }): Props => {
  const statusCode = res ? res.statusCode : err ? err.statusCode : 404;

  if (statusCode === 404) {
    if (req.url.match(/\/$/)) {
      const withoutTrailingSlash = req.url.substr(0, req.url.length - 1);
      if (res) {
        res.writeHead(303, {
          Location: withoutTrailingSlash
        });
        res.end();
      }
      else {
        Router.push(withoutTrailingSlash);
      }
    }
  }

  return { statusCode };
};

That works well.

santialbo · 2020-05-11T09:00:01Z

pages/_error can't use getServerSideProps on purpose as explained in #11945 (reply in thread). pages/404.js can't use getServerSideProps on purpose too as it massively increases server load without a good reason, eg all 404 routes would server-render on-demand with the code that you wrote.

Shouldn't be this up to the developer to decide? Feels like being too babysitted here. In our case we would like to serve different 404 pages depending on the language. Now I'm forced to use a useEffect inside the 404 page to trigger the language change, which shows a flash of the English version.

Zauberfisch · 2020-10-26T12:49:14Z

Has this possibly been fixed?

I've just tested next with just index.js, _app.js and _error.js and it worked without a 404.js.

Zauberfisch · 2020-10-27T04:48:53Z

nvm, this bug is still present.
When _error.js has getInitialProps a 404.js is not required, but otherwise it is

MerlinMason · 2022-05-03T14:44:03Z

Yeah this seems confusing.

I followed the steps detailed in the Sentry docs, which makes no mention of also requiring a 404 file as well as a _error file.

However, this is contradicted in the Next example with Sentry.

Intuitively, it makes sense I can either have a specific 404 page, or a general error page.

As it stands, it's not clear why both are required, what the dependency is between them, or what the logic is to determine which one to show.

timneutkens added the Documentation label Apr 28, 2020

ergunsh mentioned this issue Sep 3, 2020

Add Sentry in client zeplin/microsoft-teams-app#49

Merged

Timer added the kind: story label Sep 12, 2020

Timer assigned lfades Sep 12, 2020

raygervais mentioned this issue Dec 9, 2020

Port Error page from GatsbyJS to Next.js Seneca-CDOT/telescope#1468

Closed

Timer added this to the backlog milestone Jan 6, 2021

timneutkens unassigned lfades Nov 17, 2021

molebox assigned amandeepmittal Feb 3, 2022

balazsorban44 added Documentation Related to Next.js' official documentation. and removed area: documentation labels Apr 17, 2024

vercel locked and limited conversation to collaborators Apr 17, 2024

balazsorban44 converted this issue into discussion #64631 Apr 17, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

This issue was moved to a discussion.

Cannot have an _error.tsx file without a 404.tsx file #12256

Cannot have an _error.tsx file without a 404.tsx file #12256

eiskalteschatten commented Apr 27, 2020

timneutkens commented Apr 28, 2020

timneutkens commented Apr 28, 2020

timneutkens commented Apr 28, 2020 •

edited

Loading

eiskalteschatten commented Apr 28, 2020

eiskalteschatten commented Apr 28, 2020

santialbo commented May 11, 2020 •

edited

Loading

Zauberfisch commented Oct 26, 2020 •

edited

Loading

Zauberfisch commented Oct 27, 2020

MerlinMason commented May 3, 2022

This issue was moved to a discussion.

This issue was moved to a discussion.

Cannot have an _error.tsx file without a 404.tsx file #12256

Cannot have an _error.tsx file without a 404.tsx file #12256

Comments

eiskalteschatten commented Apr 27, 2020

Bug report

Describe the bug

To Reproduce

Expected behavior

System information

Additional context

timneutkens commented Apr 28, 2020

timneutkens commented Apr 28, 2020

timneutkens commented Apr 28, 2020 • edited Loading

eiskalteschatten commented Apr 28, 2020

eiskalteschatten commented Apr 28, 2020

santialbo commented May 11, 2020 • edited Loading

Zauberfisch commented Oct 26, 2020 • edited Loading

Zauberfisch commented Oct 27, 2020

MerlinMason commented May 3, 2022

This issue was moved to a discussion.

timneutkens commented Apr 28, 2020 •

edited

Loading

santialbo commented May 11, 2020 •

edited

Loading

Zauberfisch commented Oct 26, 2020 •

edited

Loading