route.ts files being executed during build

[davecarlson]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:23 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6020
    Binaries:
      Node: 18.16.0
      npm: 9.5.1
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:r
      next: 13.4.8
      eslint-config-next: 13.4.2
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 4.9.5
    Next.js Config:
      output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true)

Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/cranky-heyrovsky-g5zgpm?file=%2Fapp%2Froute.ts%3A1%2C1

To Reproduce

npm run build

The "username is required" is from the API call to twilio, that should never ever ever be executed at build.

Describe the Bug

When I run npm run build, the compiler is attempting to run my route handler. This should not happen. My application ONLY contains route handlers, and no frontend (as it is an API).

What this is calling:

• build is calling my database via prisma
• it is then trying to send out a tonne of SMS messages

This is a webhook, and if this is "Desired behaviour", there needs to be a SIMPLE way to turn it off.

Expected Behavior

The code is compiled, but not exected

Which browser are you using? (if relevant)

n/a

How are you deploying your application? (if relevant)

happens locally

[davecarlson]

Note:
export const dynamic = "force-dynamic" seems to do nothing to stop this.

[Fredkiss3]

Hello, @davecarlson , i've tested your bug here https://stackblitz.com/edit/github-pawf6k?file=app%2Froute.ts and i cannot reproduce your bug, when i run a build the route.ts file seems to not be executed and everytime i call the route, it show me the current time (so it is not cached). You can test by yourself

From what i've seen in the logs on codesandbox, it seems the version installed there is a very old one : It still logs a message asking for feedback on App Router, but this message have been removed since version 13.4.0 where they declared next App Router stable.

You may try to reproduce the problem locally or in stackblitz, with the latest version installed. On my end, everything seems to work fine

[balazsorban44]

Indeed, the lock file shows that you have 13.1.7-canary.10 installed. Please upgrade.

https://github.com/twilio/twilio-node#environment-variables Based on this, it's also likely that Twilio throws the errors at build time on purpose.

[github-actions]

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases. You can also use the GitHub templates (preferred) for pages and App Router, or the CodeSandbox: pages or CodeSandbox: App Router templates to create a reproduction with canary from scratch.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without reproduction steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[lazarv]

@balazsorban44 @Fredkiss3 here's a repro of this bug: https://stackblitz.com/edit/stackblitz-starters-utiqwb?file=app%2Froute.js using Next.js 13.4.9

The route.js contains this minimal code:

import { NextResponse } from 'next/dist/server/web/spec-extension/response';
import { redirect } from 'next/navigation';

export async function GET(request) {
  try {
    const res = await fetch('https://www.google.com', { cache: 'no-store' });
    const data = await res.text();
    console.log(data);

    const url = new URL(request.url);
    const { searchParams } = url;
    const q = searchParams.get('q') || 'foobar';
    console.log(q);

    return NextResponse.json({ q });
  } catch (e) {
    console.log(e);
    redirect('https://www.google.com');
  }
}

Try to npm run build and you can see, that the console.log message is visible during build in the "Generating static pages" phase:

If I remove the code which is trying to use fetch, so it is:

import { NextResponse } from 'next/dist/server/web/spec-extension/response';
import { redirect } from 'next/navigation';

export async function GET(request) {
  try {
    const url = new URL(request.url);
    const { searchParams } = url;
    const q = searchParams.get('q') || 'foobar';
    console.log(q);

    return NextResponse.json({ q });
  } catch (e) {
    console.log(e);
    redirect('https://www.google.com');
  }
}

Then during build, we can see that the catched error is a DynamicServerError.

When using like a temporary file write, the file exists after build:

import { NextResponse } from 'next/dist/server/web/spec-extension/response';
import { redirect } from 'next/navigation';
import { writeFile } from 'node:fs/promises';

export async function GET(request) {
  try {
    await writeFile('tmp.txt', new Date().toISOString(), 'utf-8');

    const res = await fetch('https://www.google.com', { cache: 'no-store' });
    const data = await res.text();
    console.log(data);

    const url = new URL(request.url);
    const { searchParams } = url;
    const q = searchParams.get('q') || 'foobar';
    console.log(q);

    return NextResponse.json({ q });
  } catch (e) {
    console.log(e);
    redirect('https://www.google.com');
  }
}

All of this is probably happening because Next.js is trying to pre-render route handlers and when try..catch is removed, then handles an error which happens when request.url is used. This should not happen.

An app router route.js should work the same way as the API routes in pages, without any pre-rendering when needed. Method used to figure out if the route is static or dynamic has a side-effect right now which could cause serious issues in some use cases.

[asmockler]

I am also having this issue.

In my case, it is making it difficult to initialize some packages (like twilio) because not all of my environment variables are available during the build step. So, these packages throw errors, even though the desired result is just that the code compiles to be run where those environment variables exist.

[mgustus]

In the route.ts I have:

export const dynamic = "force-dynamic";

Why the GET handler in route.ts is being executed during build?

[balazsorban44]

This issue has been automatically closed because it wasn't verified against next@canary. If you think it was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.

[lazarv]

@balazsorban44 I updated my repro example to use next@canary at https://stackblitz.com/edit/stackblitz-starters-tgm2xw?file=app%2Froute.js

See more details in my previous comment. This is still in issue.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.