-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
adapter-cloudflare: allow disabling generation of fallback 404.html
#9762
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
adapter-cloudflare: allow disabling generation of fallback 404.html
#9762
Conversation
🦋 Changeset detectedLatest commit: f2413f7 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
I'd go one step further and prevent generating a fallback if there are no prerendered pages in the cloudflare adapter. |
Would dealing with #9802 remove the need for this? It would be nice not to need another option. |
I believe it would. The only reason for this option was that the fallback generation was breaking people's builds. |
It would not. Completely removing the fallback page would cause any 404s to non-function routes to show the / page instead of a 404 page In its current state, the option would only be needed if it breaks your build. It defaults to the same behavior as before. I probably will get around to implementing @s3812497 ’s suggestion to automatically not generate it if there are no pre-rendered pages |
The proposed solution actually implements a static 404.html by default too. This would be without running hooks |
It would implement it for the appDir, not the actual app. The fallback page would still be needed for the actual app to ensure that 404s in the app will have the correct behavior. |
If the user has opted-in to use wildcard matching for static requests, perhaps fallback generation should be opt-in/ handled by them as well. |
The simpler way would be, if unset, to only generate it if there are pre-rendered pages, as you suggested earlier |
…f no fallback page is generated
…rated when it shouldn't
The latest commit should address all previous issues with this.
|
404.html
404.html
@@ -49,6 +51,16 @@ The `routes` option allows you to customise the [`_routes.json`](https://develop | |||
|
|||
You can have up to 100 `include` and `exclude` rules combined. Generally you can omit the `routes` options, but if (for example) your `<prerendered>` paths exceed that limit, you may find it helpful to manually create an `exclude` list that includes `'/articles/*'` instead of the auto-generated `['/articles/foo', '/articles/bar', '/articles/baz', ...]`. | |||
|
|||
### Generate 404 | |||
|
|||
The `generate404` option allows you to specify whether a fallback `404.html` page will be generated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should rename this to generateFallback
so it better matches with the error message users get during build.
> Using @sveltejs/adapter-cloudflare
file:///Users/my-app/node_modules/@sveltejs/kit/src/core/postbuild/fallback.js:53
throw new Error(`Could not create a fallback page — failed with status ${response.status}`);
documentation/docs/25-build-and-deploy/60-adapter-cloudflare.md
Outdated
Show resolved
Hide resolved
…generation # Conflicts: # packages/kit/src/core/adapt/builder.js
Co-authored-by: Tee Ming <[email protected]>
documentation/docs/25-build-and-deploy/60-adapter-cloudflare.md
Outdated
Show resolved
Hide resolved
@@ -16,13 +16,27 @@ export default function (options = {}) { | |||
builder.rimraf(tmp); | |||
builder.mkdirp(tmp); | |||
|
|||
// generate 404.html first which can then be overridden by prerendering, if the user defined such a page |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we still account for user-defined 404.html pages before generating it for them? Right now we would be overwriting them as it's generated after the prererendered pages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea it might be better to move this back about builder.writePrerendered
line
* | ||
* @default auto | ||
*/ | ||
generate404?: boolean | 'auto'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be named something like fallback
?
Co-authored-by: Tee Ming <[email protected]>
The default value of `auto` will only generate a fallback `404.html` page if there are *any* prerendered pages. | ||
|
||
You may want to set this to `false` if you have a fully dynamic app that does not prerender pages during build time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default value of `auto` will only generate a fallback `404.html` page if there are *any* prerendered pages. | |
You may want to set this to `false` if you have a fully dynamic app that does not prerender pages during build time. | |
The default value of `auto` or `true` will generate a fallback page if prerendering occurs. This will be generated from your [error page](https://kit.svelte.dev/docs/routing#error). |
You may want to set this to
false
if you have a fully dynamic app that does not prerender pages during build time.
I don't think we need to say this, as auto
would prevent this anyway? If we want to mention false
then we could say something like Set this option to
false to prevent generating a fallback.
I've gone round in circles trying to understand this PR, #9386, #9011 and #9802, and here's where I'm at: As far as I can tell, there's no real reason to ever generate an SPA-style fallback The only time we need a Am I missing anything? |
Specifically my use case for it is that I generally exclude some routes that are usually checked by vulnerability scanners (to save on a few invocations). For example:
I would like for these to have the same 404s as the rest of my site. Another use case I can think for it is prerendered pages with rest parameters. For example, if you have a personal site that has some stuff that requires server logic, aswell as a static blog. You can exclude Adding the option would allow devs to manually control whether the SPA is used or the static page is used, if there is some circumstance that was not thought of in this PR (like what happened in #9386 ) |
Yeah, I did consider the latter option, but thought it was probably overkill. But it would be easy enough to implement. If we were to do that I think we could ditch the 'is something prerendered or not?' logic because it seems a bit complicated and I'm not totally sure why it's relevant — it could just be an option like this: import adapter from '@sveltejs/adapter-cloudflare';
export default {
kit: {
adapter: adapter({
fallback: 'spa' // 'plaintext' (default) or 'spa'
})
}
}; Thoughts? |
(Honestly, this would all be so much easier if Cloudflare just let you exclude all static assets, or did away with the arbitrary 100 route restriction, so that hacks like |
closed by #11596 which now does not generate a fallback by default and provides the ability to do so through the adapter config. |
Adds an option that will allow you to disable the automatic generation of 404.html if, for example, your site is fully dynamic and should not process any pages during build time.
The default option of
auto
will only generate the fallback page if there are any pre-rendered pages.#9386 (comment)
closes #9386
This PR also edits the docs to describe the new option.
I have tested this before posting, and the behavior of the option is as intended:
generate404: undefined
=> generated only if there are any pre-rendered pagesgenerate404: 'auto'
=> generated only if there are any pre-rendered pagesgenerate404: true
=> generatedgenerate404: false
=> not generatedIf no pre-rendered page is generated, a simple
404.html
is generated in/_app/404.html
to prevent a resurgence of #9011 usingsrc/error.html
if it exists, otherwise the default error page.Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
Ideally, include a test that fails without this PR but passes with it.N/A: adapter-cloudflare has no testsTests
pnpm test
and lint the project withpnpm lint
andpnpm check
Changesets
pnpm changeset
and following the prompts. Changesets that add features should beminor
and those that fix bugs should bepatch
. Please prefix changeset messages withfeat:
,fix:
, orchore:
.