[NEXT-853] Running development mode on fresh create-next-app not working

[aaronsweeneyweb]

Verify canary release

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

Provide environment information

Operating System:
Platform: darwin
Arch: x64
Version: Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64
Binaries:
Node: 18.13.0
npm: 8.19.3
Yarn: N/A
pnpm: N/A
Relevant packages:
next: 13.1.6
eslint-config-next: N/A
react: 18.2.0
react-dom: 18.2.0

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

CLI (create-next-app)

Link to the code that reproduces this issue

N/A

To Reproduce

Run npm run dev from root directory of project.

Package.json:

{
  "name": "next-base",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
  "dependencies": {
    "@next/font": "13.1.6",
    "next": "13.1.6",
    "react": "18.2.0",
    "react-dom": "18.2.0"
  }
}

Describe the Bug

When running npm run dev on a fresh create-next-app, the dev server is not starting, no errors are logged in the terminal - it just kills the command and shows the terminal cursor again. Localhost is not being used by another application.

Expected Behavior

Dev server to spin up in localhost:3000.

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_NEXT-853

[mikebuilds]

+1 looks like I'm having the same issue. My repo was working perfectly on windows, but can't get the dev server to start up on Mac.

[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 template (preferred), or the CodeSandbox or StackBlitz 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 repro 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

[mikebuilds]

Additional note, rolled all the way back to next@13.0.0 to have it working again. Even 13.0.1 was still crashing with the same issue.

[mikebuilds]

Can confirm next@canary still experiences the same issue. @balazsorban44

[aaronsweeneyweb]

Additional note, rolled all the way back to next@13.0.0 to have it working again. Even 13.0.1 was still crashing with the same issue.

Thanks @MJtH - Working for me on 13.0.0 too. Will just use that for now.

[mikebuilds]

Looking back at the commit history, perhaps an issue with this one

@ijjk - CLI/bin isn't my speciality, any chance you could look into if this would cause some issues with older macs?

[balazsorban44]

Additional note, rolled all the way back to next@13.0.0 to have it working again. Even 13.0.1 was still crashing with the same issue.

This is very helpful, could you maybe pin down the exact canary release this way too (13.0.1-canary.0 - 13.0.1-canary.4)? 🙏 The commit you link to does sound relevant.

[ijjk]

@MJtH can you add a screen recording showing the behavior you are seeing if no errors are being shown that can be shared?

[AndreLSilva]

Just to add some information: I'm also on next: 13.1.6 and experiencing a really similar (if not the same) issue, but for me the dev server doesn't exit, just stays there as if it was working properly.
I'm using Ubuntu via WSL on Windows.

[ZiBuDo]

+1 saw this issue, when I debug the stack trace I get the issue to point at _webpack.webpack.DefinePlugin is undefined because the import seems to not have called the _webpack.init() method, if I do this manually with breakpoints I get further, but I get it working on 13.0.0 as stated above

[mikebuilds]

@MJtH can you add a screen recording showing the behavior you are seeing if no errors are being shown that can be shared?

Here is a video of next@latest, with a fresh create next-app.

next@latest.mov

@balazsorban44

• next@13.0.1-canary.0 is the latest version that I can get to work correctly.
• next@13.0.1-canary.1 onwards fails with a SIGSEGV error, unsure if it's related or not. Rolling back to other versions above this will also give me a "Command failed with exit code 1". Unsure if this is a yarn issue.
• next@13.1.3-canary.5 is when any error seems to have disappeared, and the command finishes without starting the dev server.

[gcd253]

I was experiencing a very similar issue on next: 13.1.6

After installing the canary version, npm run dev was was working as intended. I am on Mac

[ZiBuDo]

When I run on 13.0.0 I see:

in next/dist/server/config.js

When I run on canary 13.1.7-11 I see:

The error I ultimately get on canary is:

Failed to start next js server TypeError: Cannot read properties of undefined (reading 'ProvidePlugin')
at Object.getBaseWebpackConfig [as default] (\node_modules\next\src\build\webpack-config.ts:2019:21)
at async Promise.all (index 0)
at Span.traceAsyncFn (\node_modules\next\src\trace\trace.ts:106:14)
at Span.traceAsyncFn (\node_modules\next\src\trace\trace.ts:106:14)
at HotReloader.start (\node_modules\next\src\server\dev\hot-reloader.ts:584:26)
at DevServer.prepare (\node_modules\next\src\server\dev\next-dev-server.ts:731:5)
at ViewService.createServer (\src\server\view\view.service.ts:21:9)
at bootstrap (\src\server\main.ts:77:5) {stack: 'TypeError: Cannot read properties of undefined...\src\server\main.ts:77:5)', message: 'Cannot read properties of undefined (reading 'ProvidePlugin')'}

If the loadWebpackHook this doesn't happen for me, I remove the conditional load and the server starts fine for me.

Looks like this commit introduced this condition:
aa0664c
Any reason why this is needed?

This only happens for me when I run the next js server in dev mode, when I build out my production build it runs fine

[Juugis]

on next:^13.2.1 getting error: TypeError: Cannot read properties of undefined (reading 'ProvidePlugin') while building custom dev server. Production environment works fine. next:^13.0.1 does not have this issue. Please fix.

[frankda]

Experiencing the same issue with next 13.2.1, getting error: TypeError: Cannot read properties of undefined (reading 'ProvidePlugin') while building custom dev server. Raised details in #46588. Stackbliz link: https://stackblitz.com/edit/nextjs-n5mjba?file=package.json,.vscode%2Fsnippets.json

[farhan2077]

Can confirm this issue still exists in nextjs 13.2.4. So installed nextjs 13.0.0 as per suggestion. My current dependencies look like this:

However downgrading to version 13 introduces another problem.

Removing instances of next/font removes the error but this is not a proper solution.

UPDATE:
Instead of downgrading nextjs, I downgraded installed node to 16.9.1 and now it's working with latest nextjs 13.2.4. However, again this is not a solution either.

[karlhorky]

Looks like this commit introduced this condition:
aa0664c
Any reason why this is needed?

@ijjk do you think aa0664c (your PR with the experimental precompiled next-server #43198) may be breaking things here as well, as @farhan2077 mentioned above?

Maybe it could be breaking things in these other issues too:

• Custom dev server get Error: TypeError: Cannot read properties of undefined (reading 'ProvidePlugin')  #46588
• in Next.js latest (v13.1.6), cannot find webpack module when running custom express server. #45464

[Veath]

I have similar problem

➜  ai-app git:(main) ✗ npx --no-install next info

    Operating System:
      Platform: darwin
      Arch: x64
      Version: Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64
    Binaries:
      Node: 18.15.0
      npm: 9.5.0
      Yarn: N/A
      pnpm: 7.18.2
    Relevant packages:
      next: 13.2.4
      eslint-config-next: 13.1.0
      react: 18.2.0
      react-dom: 18.2.0

warn  - Latest canary version not detected, detected: "13.2.4", newest: "13.2.5-canary.28".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue

pnpm run dev automatically exits without an error message, but pnpm run build has the following error message

ai-app git:(main) ✗ pnpm run build  

> ai-app@0.1.0 build /Users/xxx/xxx/ai-app
> next build

info  - Linting and checking validity of types  
info  - Creating an optimized production build ..[1]    74295 segmentation fault  pnpm run build

[rdimascio]

@ijjk I've tracked down the conditional loading of compiled Webpack to be the culprit - https://github.com/vercel/next.js/pull/43198/files#diff-7836d903b56ef6914ef5f3e8d1711c1d353d7b6ae4efefb0d2193897ee4fca85R837-R839

I removed the if (!customConfig) condition from my local next@13.2.4 build and everything is working as expected when using conf. Could you provide some details on why this conditional loading was introduced?

[stern-shawn]

UPDATE: Instead of downgrading nextjs, I downgraded installed node to 16.9.1 and now it's working with latest nextjs 13.2.4. However, again this is not a solution either.

I've been running into SIGSEGV and silent crashes all day trying to get my application working on my chromebook (crostini) instead of my mac. Downgrading Node to 16.9.1 finally has it working for me locally, thank you ❤️

[lizardlove]

still open, I have same issue right now. I use next@latest init a new project, yarn dev can not work. I downgrade next@13.0.0, there are error 'can not import next/font/google`.

UPDATE: Instead of downgrading nextjs, I downgraded installed node to 16.9.1 and now it's working with latest nextjs 13.2.4. However, again this is not a solution either.

I've been running into SIGSEGV and silent crashes all day trying to get my application working on my chromebook (crostini) instead of my mac. Downgrading Node to 16.9.1 finally has it working for me locally, thank you ❤️

Saddly, I downdraged node to 16.9.1, it's not working with nextjs@13.3.0.

[loozhengyuan]

I encountered the same issue locally while running next build as part of building the Docker image. Using node:18.17.0-bookworm-slim encounters segmentation fault while downgrading to node:16.20.2-bookworm-slim has no issues. Oddly enough, when I try to create a repro via GitHub Actions, both image passes. Not too sure what the issue is.