localhost port number confusion and strange behaviour on different ports when running an Astro project

[whitep4nth3r]

Describe the bug

There's conflicting information in the CLI output when running netlify dev for an Astro project. (This actually also apply to other frameworks where they use a different port for by default.)

When you run netlify dev and the framework portion of the output appears, you see that Astro is going to start on port 3000 in two separate messages.

First:

> astro dev

  🚀  astro  v2.0.2 started in 31ms

  ┃ Local    http://127.0.0.1:3000/
  ┃ Network  use --host to expose

Second:

✔ Waiting for framework port 3000. This can be configured using the 'targetPort' property in the netlify.toml

However, the CLI opens a browser window on port 8888 and states that the development server is ready on this port.

◈ Server now ready on http://localhost:8888

HOWEVER, this is where things get a little weird.

The following behaviour is found in this Astro project.

Features of this project (using the new hybrid rendering of Astro 2.0):

1. It's using the Netlify Edge Adapter as detailed in the config file
2. index.html is using edge SSR
3. A number of pre-rendered routes are created at build time

The weird stuff

1. When I run netlify dev, BOTH localhost:3000 and localhost:8888 serve the index.html page.
2. ONLY localhost:3000 serves the prerendered routes!
3. Furthermore on localhost:8888 the CSS file gives a 404 but is served correctly on localhost:3000.

09:39:47 AM [serve] 404           /_astro/_clip_id_.8041319c.css

This issue is also recreated on the deployed site where the index.html is served correctly, but all prerendered routes return a 404. Interestingly the CSS is served correctly on the live site.

I submitted this as a CLI issue initially due to the port confusion, but there's also something going on with the build process on a live site.

Steps to reproduce

In development using the Netlify CLI:

1. Clone this Astro project.
2. Run netlify dev and observe that both localhost:3000 and localhost:8888 serve the index page.
3. Scroll down to the hidden links on the index page, and navigate to one of the prerendered routes.
4. Observe that on localhost:3000 the prerendered routes are served, but on localhost:8888 they 404.

On the live site:

1. Visit this live site
2. Notice that the index page renders correctly
3. Visit a prerendered route, such as this one and notice that it returns a 404.

Configuration

[build]
  command = "astro build"
  publish = "dist"

Environment

  System:
    OS: macOS 13.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 961.39 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.19.0 - ~/.nvm/versions/node/v16.19.0/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 8.19.3 - ~/.nvm/versions/node/v16.19.0/bin/npm
 npmGlobalPackages:
    netlify-cli: 12.10.0

[orinokai]

I had an initial look at this one, @whitep4nth3r. The port confusion is something that affects every framework, as you mentioned. The CLI has to wait for the dev server on the original port before proxying to it on 8888, but I guess we could improve the messaging around this. Something like, "Netlify Dev now ready on http://localhost:8888" or "Netlify Dev now serving Astro on http://localhost:8888"?

When I clone your repro I get slightly different behaviour to that you mentioned: everything seems to work okay with netlify dev, but is completely broken on production: https://repro-astro-dev.netlify.app/

However, I can observe the behaviour you described (index pages works, but links 404) if I run netlify serve so that gives us something to work with. Going to add this issue to the Up Next column for further investigation.

[whitep4nth3r]

Hmm that is interesting.

In other news, I did some more testing.

I switched the Edge SSR to regular SSR and the site works as expected (on localhost:3000 on dev) and in production.

[radianrad]

I am running into a similar issue I think with Astro and SSR. See #6496.

I am not sure if this is related, but seemingly at random, serving the CSS files will fail when viewing the site without a file extension using the Netlify port, whereas 3000 appears to work. I have to delete the repo and re-clone/re-install for it to clear. Deleting astro and .netlify do not work so maybe it's a cache elsewhere.

The stylesheet ... was not loaded because its MIME type, “text/html”, is not “text/css”.

[whitep4nth3r]

I, too, have experienced the above issue from @christianpetty!

[radianrad]

I’ll clarify that I’m using edge functions.

[whitep4nth3r]

Just wanted to bump this issue as it came up again today.

I'm using Auth.js to authenticate via Twitch in an Astro project, using the Netlify CLI for local development.

In development, everything was going great on the default CLI port of 8888 until I installed Sentry in my project, which as far as I'm aware, generates some kind of middleware handler.

After Sentry was installed, authentication via Auth.js no longer worked in development on port 8888, yet it continued to work in production.

The console errors in development looked like this, despite everything working in production:

13:59:05 [200] /api/auth/csrf 4ms
›   Warning: Missing form submission function handler
Request from ::1: POST /api/auth/signin/twitch?
Response with status 404 in 1 ms.
›   Warning: Missing form submission function handler
Request from ::1: POST /api/auth/signin/twitch.html
Response with status 404 in 0 ms.
›   Warning: Missing form submission function handler
Request from ::1: POST /api/auth/signin/twitch.htm
Response with status 404 in 0 ms.
›   Warning: Missing form submission function handler
Request from ::1: POST /api/auth/signin/twitch/index.html
Response with status 404 in 0 ms.
›   Warning: Missing form submission function handler
Request from ::1: POST /api/auth/signin/twitch/index.htm
Response with status 404 in 0 ms.

After struggling for around 2 hours, I remembered this issue and changed the local port number to 4321, and auth in development started working as expected.

Just wanted to give another update to this issue, given it continues to plague me.

Have a great day! 👋🏼

[serhalp]

Hey @whitep4nth3r, sorry for the delays on this one — since it's been 18 months and there's been a bit of back and forth and some overlap between this issue and some others you've reported, would you mind providing an update on this?

We're aware that the netlify dev output is confusing, since it mentions multiple running local server URLs/ports¹. Are there any additional reports here that are still valid? If so, would you be able to provide an up-to-date repro?

Thanks!

¹ P.S. We may have an awesome solution for this coming later this year 🤫.

[whitep4nth3r]

So the update is that this issue isn't just with Astro, as I'm encountering it with a Nuxt project as well (coincidentally, using Twitch auth).

Basically, the window that the Netlify CLI opens on port 8888 by default can trip a lot of people up when working with some features of frameworks. The bottom line is that port 8888 (for reasons beyond my comprehension) doesn't work for a lot of modern architecture patterns such as middleware in meta frameworks.

Personally, I now make sure to open localhost using the default framework port as specified in the CLI output when running netlify dev. This annoyance could be solved by the CLI not opening a browser tab and letting developers open localhost in the browser using the port of their choice (which should probably be the default framework port as reported in the CLI output anyway).

[serhalp]

Thank you, Salma.

While we acknowledge that the current experience could be better — and like I hinted above, we're hoping to have a much simpler solution for this eventually that makes all this moot — the current intention is for developers to use the netlify dev URL (localhost:8888), not the framework's native URL.

If there are specific features that aren't working in specific frameworks, please open an issue in the appropriate repo or post on https://answers.netlify.com/. We definitely intend for netlify dev to have near feature parity with the Netlify platform, so please report any issues you've encountered.

I'm going to close this one, hope that's ok.

[whitep4nth3r]

According to my experience, anything that uses middleware in Nuxt or Astro means that port 8888 fails weirdly. A recent example (from June this year) was explained in this comment above. https://github.com/netlify/cli/issues/5433#issuecomment-2152417970

Please let me know where the correct place is to re-report this.

Also, please let me know the correct place to report the same issue with a Nuxt project.