Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building Next.js root page on netlify dev [v3.4.2+] #1815

Closed
spencewood opened this issue Jan 26, 2021 · 2 comments · Fixed by #1817
Closed

Building Next.js root page on netlify dev [v3.4.2+] #1815

spencewood opened this issue Jan 26, 2021 · 2 comments · Fixed by #1817
Assignees
Labels
type: bug code to address defects in shipped code

Comments

@spencewood
Copy link

Describe the bug

I run a site on Netlify with a pretty large codebase in Next.js using the "Next on Netlify" plugin. Because of the size and it having to be compiled from TypeScript, it can take a few seconds to compile and be ready via the Netlify cli proxy server. Since the introduction of #1795 in v3.4.2, it builds the root page during initialization not once, but multiple times, making it take upwards of 20 seconds for it to be fully ready.

❯ yarn dev
yarn run v1.22.10
$ netlify dev
◈ Netlify Dev ◈
◈ Ignored general context env var: LANG (defined in process)
◈ Functions server is listening on 53360
◈ Starting Netlify Dev with next
$ next
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
ready - started server on http://localhost:3000
info  - automatically enabled Fast Refresh for 1 custom loader
info  - Using external babel configuration from ...
event - compiled successfully
event - build page: /
wait  - compiling...
event - build page: /
event - build page: /
event - build page: /
event - build page: /
event - build page: /
(node:12165) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 / listeners added to [EventEmitter]. Use emitter.setMaxListeners() to increase limit
...
...
event - compiled successfully
   ┌─────────────────────────────────────────────────┐
   │                                                 │
   │   ◈ Server now ready on http://localhost:9000   │
   │                                                 │
   └─────────────────────────────────────────────────┘

This takes 20+ seconds, whereas before, it took about 6.

What's happening here is that Next.js compiles pages on url request, and since the Netlify cli now "pings" the root url every 150 milliseconds during initialization to see if the server is ready and Next.js is still compiling it, it continually kicks off new builds until (I think) the original build is ready. The "event listener" warning is a direct result of this and ends up slowing down significantly because it is building the root page several times at the same time.

To Reproduce

While my main repo is private, I have created small demo app that illustrates the issue (albeit with a much smaller performance impact):

https://github.com/spencewood/sonnet-18

> yarn
> yarn netlify dev
yarn run v1.22.10
$ netlify dev
◈ Netlify Dev ◈
◈ Ignored general context env var: LANG (defined in process)
◈ Functions server is listening on 54593
◈ Starting Netlify Dev with next
$ next
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
ready - started server on http://localhost:3000
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
event - compiled successfully
event - build page: /
wait  - compiling...
event - build page: /    
event - build page: /   <--- building multiple times
event - build page: /
event - build page: /
event - compiled successfully

   ┌─────────────────────────────────────────────────┐
   │                                                 │
   │   ◈ Server now ready on http://localhost:8888   │
   │                                                 │
   └─────────────────────────────────────────────────┘

event - build page: /next/dist/pages/_error
wait  - compiling...
event - compiled successfully

Unless you've got a computer that can compile this very fast, you'll notice multiple build events during init.

On v3.4.1 it looks like the following:

❯ yarn netlify dev
yarn run v1.22.10
$ netlify dev
◈ Netlify Dev ◈
◈ Ignored general context env var: LANG (defined in process)
◈ Functions server is listening on 54959
◈ Starting Netlify Dev with next
$ next
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
ready - started server on http://localhost:3000
Browserslist: caniuse-lite is outdated. Please run:
npx browserslist@latest --update-db
event - compiled successfully
event - build page: /
wait  - compiling...
event - build page: /
event - compiled successfully

   ┌─────────────────────────────────────────────────┐
   │                                                 │
   │   ◈ Server now ready on http://localhost:8888   │
   │                                                 │
   └─────────────────────────────────────────────────┘

Expected behavior

I wouldn't expect Netlify cli to make network requests to my backend server during initialization, especially not at such an aggressive interval (even HEAD requests trigger Next.js to build the page). I'm just not sure that this is a one-size-fits-all solution and there should be a different way to determine if a server is up, or alternatively, a way to opt into (or out of) this kind of checking.

@spencewood spencewood added the type: bug code to address defects in shipped code label Jan 26, 2021
@eduardoboucas eduardoboucas self-assigned this Jan 26, 2021
@eduardoboucas
Copy link
Member

Hi @spencewood. We've recently introduced that logic to address an issue with a different framework hanging when running netlify dev, and unfortunately this looks like an undesired side-effect that we didn't account for. I should be able to cut a release with a fix soon.

Thanks for creating the issue with such detailed information.

@eduardoboucas
Copy link
Member

@spencewood This should be fixed in version 3.4.4. If not, please feel free to reopen the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug code to address defects in shipped code
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants