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

Build fails using server islands and static output mode #498

Closed
1 task done
JannikWempe opened this issue Jan 8, 2025 · 8 comments
Closed
1 task done

Build fails using server islands and static output mode #498

JannikWempe opened this issue Jan 8, 2025 · 8 comments

Comments

@JannikWempe
Copy link

JannikWempe commented Jan 8, 2025

Astro Info

Astro                    v5.1.3
Node                     v18.20.3
System                   Linux (x64)
Package Manager          npm
Output                   static
Adapter                  @astrojs/vercel
Integrations             none

Describe the Bug

Rendering a server island (adding server:defer to any component), using adapter vercel (can also reproduce it with sst) and output: "static" results in this error:

[NoAdapterInstalledServerIslands]

It works fine with the netlify adapter though.


This is a discussion about the issue on Discord with @louisescher.

What's the expected result?

The build should work using server islands and a static output mode. (It does using the netlify adapter.)

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-s2hf8p8k

Participation

  • I am willing to submit a pull request for this issue.
@AirBorne04
Copy link
Contributor

Not sure what the implications of this is, but i have found the following.

  • Cloudflare adapter works
  • the error message depends on the buildOutput returned from the adapter like here and needs to be server in order to work as expected
  • vercel specifies static or server as output (making it the same as the output)

switching the buildSetting to server on the vercel adapter makes the error go away, but i am not sure about other implications.

@JannikWempe
Copy link
Author

JannikWempe commented Jan 9, 2025

Not sure what the implications of this is

I know one implication (because it was the reason I discovered this).

I wanted to cache a server island using cache headers. That did not work because the p param of the generated path from where the data for that island is fetched changes on each request. p contains the encrypted props of that island. My props were static, but p changes on each request, which causes cache misses. p changes because encrypting is done using a random iv (see here).

Server output causes p to change in each request. Only static output will cause a stable p and therefore cachable server island.

TLDR; You can't cache server islands.

That is why it is not an option to just use server output.

@AirBorne04 AirBorne04 linked a pull request Jan 10, 2025 that will close this issue
@AirBorne04
Copy link
Contributor

Hi @JannikWempe

I got the issue, I verified that the output is as expected when changing the adapter options, small fix that should do. Can you also check if this is the fix you were looking for?

@JannikWempe
Copy link
Author

Hey @AirBorne04 thanks for working on a fix.

I was able to build the project locally with output: "static" using your changes. I didn't manage to deploy it to Vercel though (seeing 404). But that may be just my incompetence 😅 I did run astro build and tried to deploy my prebuilt files directly with vercel deploy --prebuilt.

@AirBorne04
Copy link
Contributor

Hi @JannikWempe

I did a little more digging and hit some issues but also came to a possible easy solution.

When we set output="static" the adapter builds different than output="server". From what I do understand is that we actually have two steps in building the astro project with an adapter. In a simplified way it is step one building the Astro Project that can be ("static" | "server") than we do have the adapter (like layout the files to fit a certain deployment environment) which by its nature is always for a server/runtime.

Therefore I would think that the adapter always should build in "server" config, I tried settings this but for some (currently unknown to me) reason that does not result in the correct build (call to _server_island fails) while doing the same with output="server"works. I need to dig a little deeper what the issue is here.

But what I found that setting export const prerender = true for the index.astro has the effect wanted. Maybe you can give this a try.

I think that should generally be the way to go, since this is more of a Astro project concern how the files are build, not what the layout for the runtime should be.

@JannikWempe
Copy link
Author

Adding export const prerender = true does indeed work as expected 👍🏼

With this, using output: "server" doesn't seem to be an issue.

It is inconsistent though, that some adapters behave differently, for example:

  • vercel would need output: "server" and export const prerender = true on the route
  • netlify would only need output: "static" (no export const prerender = true needed)

@AirBorne04
Copy link
Contributor

I agree that they should behave the same. In my opinion they should be considered server (edge or non edge) so basically ignoring this setting altogether unless I am missing something and ultimately work like the netlify adapter already does. In the vercel adapter the static and server config from the project would influence the output which I think is wrong. If the adapter has the need for a config it should be configured on the adapter not on the Astro project.
So I will check what I can tweak to make the adapter work that way 👍

@JannikWempe
Copy link
Author

Thanks a ton, @AirBorne04 👍🏼

I think this issue can be closed.

Finding a consistent, minimal confusing way to handle inconsistencies seems to be a separate thing. (Feel free to reopen if you disagree.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants