* fix(node): delegate preview's not found and error handling to core/app
* add changeset
---------
Co-authored-by: Nate Moore <natemoo-re@users.noreply.github.com>
* wip: support true react vnodes in renderer
* Add new experimentalReactChildren option to React integration
* Update the test
* Add docs
* Update packages/integrations/react/server.js
Co-authored-by: Nate Moore <natemoo-re@users.noreply.github.com>
* Update with a better test
* Update .changeset/yellow-snakes-jam.md
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
* Update packages/integrations/react/README.md
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
* Update packages/integrations/react/README.md
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
---------
Co-authored-by: Nate Moore <nate@astro.build>
Co-authored-by: Nate Moore <natemoo-re@users.noreply.github.com>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
* Filter out Svelte's unexpected class prop console warnings
Astro's hydration code passes a `class` prop to Svelte components, inducing Svelte to log a warning about an unknown prop. Preempting this by exporting a `class` prop from the Svelte component isn't a viable workaround since `class` is a reserved identifier in JS.
This PR implements the console-filtering workaround suggested by @HiDeoo in #5665, borrowing the `useConsoleFilter` approach from the [preact integration](a1c0cbe604/packages/integrations/preact/src/server.ts (L72-L94)).
It would probably be better to generalize console filtering so it could be shared across multiple integrations.
Ideally there would be a way to handle this in Svelte, but as was pointed out in the issue thread even they resort to [similar cringe-inducing hackery](https://github.com/sveltejs/kit/blob/master/packages/kit/src/runtime/client/client.js#L1974-L1996) in sveltekit.
* Only filter Svelte console warnings in dev builds
* Add changeset
* Fix lint error.
---------
Co-authored-by: bluwy <bjornlu.dev@gmail.com>
Co-authored-by: Nate Moore <natemoo-re@users.noreply.github.com>
This was causing React components rendered with client:only
to be prefixed with null. While not technically causing any
issues, it is unintended and could be considered a bug.
Co-authored-by: Nate Moore <natemoo-re@users.noreply.github.com>
* supporting a network address access a website when an user set host = true in Node environment
* fix bug
* sumbit test code
* optimism
* delect white space
* test
* fix test
* fix test error
* test
* test
* test
* fix test error
* Optimizing code based on the comments
* optimize test
* fix: rebase issues
* chore: format
* chore: add changeset
* chore: format
* chore: format
* chore: lint
---------
Co-authored-by: wuls <linsheng.wu@beantechs.com>
Co-authored-by: Nate Moore <nate@astro.build>
* add support for advanced mode
* add support for directory mode
* use asset fallback as in cloudflare's docs
* update locals
* come up with new runtime in `Astro.locals`
* add overwrite protection
* minor cleanup
* changeset
* address review comments
* move overwrite protection to adapter
* fix types
* fix comment
* resolve review comments
* update changeset
* add test
* redo ts
* fix integration test port
* updated tests, add new port
* add TODO comment
* update changeset
* add JSDoc
* Update packages/integrations/cloudflare/src/runtime.ts
---------
Co-authored-by: Nate Moore <natemoo-re@users.noreply.github.com>
* Links with hash marks are now supported if they lead to a different page
* treat links to same page equally, independent of hash or not
* Links to the same page do not trigger view transitions
* special treatment for trailing hash
* view transitions: simpler rule to exclude in-page links
