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

Prerender with named html files #607

Closed
1 task done
slyduda opened this issue Oct 21, 2022 · 6 comments
Closed
1 task done

Prerender with named html files #607

slyduda opened this issue Oct 21, 2022 · 6 comments
Assignees
Labels
enhancement New feature or request prerender

Comments

@slyduda
Copy link

slyduda commented Oct 21, 2022

Describe the feature

The prerenderer currently prefers prerendering in subfolders. While I can take the advice of writing named html files in the prerender route config, I would prefer to make this the togglable behavior with a bool in the nitro config (similar to how there was one in Nuxt v2).

After doing some searching this was the default behavior before #166. It would be nice to have a bool that toggles this in nitro config if it does not already exist.

Additional information

  • Would you be willing to help implement this feature?
@danielroe danielroe added the enhancement New feature or request label Oct 22, 2022 — with Volta.net
@emretepedev
Copy link

emretepedev commented Dec 20, 2022

Same issue here.

I don't want to create a folder for each page.

example:
for ~/page/foo.vue

~/.output/foo/index.html (Currently file)
~/.output/foo.html (Expected file)

This behavior must be changeable via config.

@davidsandoz
Copy link

davidsandoz commented Apr 13, 2023

I would need this as well.

As already mentioned, this used to be the default before it got changed in cdcd35a via #166.

In nuxt/nuxt#13886 (where the opposite was requested, before #166 got implemented), a workaround was mentioned in this comment by @pi0:

This is now the default behavior of Nuxt 3 in latest RC to use dist/[path]/index.html (unless path has an explicit .html extension)

And indeed, if we name a page component foo.html.vue, then we get the file foo.html in .output/public/.

However, I noticed a problem with this workaround. The generated file has references to /foo.html/_payload.js:

<link rel="preload" as="fetch" crossorigin="anonymous" href="/foo.html/_payload.js">
<script type="module">import p from "/foo.html/_payload.js";window.__NUXT__={...p,...({state:{},_errors:{},serverRendered:true,prerenderedAt:1681384634837,config:{public:{},app:{baseURL:"\u002F",buildAssetsDir:"\u002F_nuxt\u002F",cdnURL:""}}})}</script>

As foo.html is not a directory, it fails at retrieving the _payload.js file, and there is actually no payload file generated for foo.html in .output/public/.

Is there a way to configure this properly? Or is this something that has to be fixed in nitro or Nuxt?

This may also be related to nuxt/nuxt#14507.

@davidsandoz
Copy link

Additionally, if I have a page component with a parameter, e.g. bar-[id].html.vue, then the link crawler doesn't generate the page even though there is the following nuxt-link in index.vue:

<nuxt-link to="bar-3.html">Bar 3</nuxt-link>

And there are no errors during generation.

While if I put bar-3 instead of bar-3.html, I get the following error:

/bar-3 (7ms) (Error: [404] Page not found: /bar-3)  

Here's a repo with minimal changes to reproduce the issue: https://github.com/davidsandoz/nuxt-starter-static-payload-reproduction/tree/v3-codesandbox-static-payload-reproduction

@manniL
Copy link
Member

manniL commented Apr 13, 2023

Most likely related to the crawling topic: #1067

@pi0
Copy link
Member

pi0 commented Aug 30, 2023

Sorry for checking on this late. I think we can introduce an experimental option experimental.prerenderIndexHTML: false to disable sub-folder behavior (path/index.html ~> path.html) ~> #1676

@Hebilicious
Copy link
Member

@pi0 Can this be closed thanks to #1676 ?

@pi0 pi0 closed this as completed Sep 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request prerender
Projects
None yet
Development

No branches or pull requests

7 participants