Skip to content

docs: fix type snippet errors - #16213

Merged
teemingc merged 1 commit into
version-3from
fix-docs-type-snippet
Jul 2, 2026
Merged

docs: fix type snippet errors#16213
teemingc merged 1 commit into
version-3from
fix-docs-type-snippet

Conversation

@teemingc

@teemingc teemingc commented Jul 2, 2026

Copy link
Copy Markdown
Member

Gets the preview site building again for the kit version-3 branch. It's a different set of docs compared to the svelte.dev main branch so it doesn't show up as an error there


Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.

Tests

  • Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

  • If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Edits

  • Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.

@pkg-svelte-dev

pkg-svelte-dev Bot commented Jul 2, 2026

Copy link
Copy Markdown

Install the latest version of @sveltejs/kit from 897b18b:

pnpm add https://pkg.svelte.dev/@sveltejs/kit/c/897b18b7445829cde6aab9fac2bed8c1c763d323

Open in pkg.svelte.dev: https://pkg.svelte.dev/repos/kit/pr/16213

@changeset-bot

changeset-bot Bot commented Jul 2, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 897b18b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

If your app is served from an origin that isn't known at request time — for example because it's behind a reverse proxy that doesn't pass the `host` header, or because you want to use a canonical origin for CSRF checks that differs from the request's host — you can set the [`paths.origin`](https://svelte.dev/docs/kit/configuration#paths.origin) option in your `vite.config.js`:

```js
// @errors: 2307

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ignores that we don't have @sveltejs/adapter-node installed thus there are no types for it

@svelte-docs-bot

Copy link
Copy Markdown

adapter: adapter(),
paths: {
origin: process.env.ORIGIN
origin: /** @type {`https://${string}`} */ (process.env.ORIGIN)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one's a little annoying because env variables are string | undefined but our type for this is pretty strict. Do we want to change it?

Note at some point we probably want to allow using $app/env/* here or just encourage the Vite pattern for accessing environment variables in the config file https://vite.dev/config/#using-environment-variables-in-config

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm yeah that's pretty annoying. I'm ok with this fix for now

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should allow paths.origin to be string | undefined, otherwise real people are going to hit this too

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also what do you mean about allowing $app/env? Surely we can't use a Vite alias inside the Vite config?)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah rats. I saw this only after seeing the approval

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Also what do you mean about allowing $app/env? Surely we can't use a Vite alias inside the Vite config?)

That's what #15250 was trying to solve by adding the aliases as paths to the generated tsconfig (was also going to try writing them to node_modules)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should allow paths.origin to be string | undefined, otherwise real people are going to hit this too

Opened #16215

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what #15250 was trying to solve

Ah I see. I think that would land us in a weird spot — what would this mean for example?

// vite.config.js
import { version } from '$app/env';
import { defineConfig } from 'vite';
import { sveltekit } from '@sveltejs/kit/vite';

export default defineConfig({
  plugins: [
    sveltekit({
      version: {
        name: version
      }
    })
  ]
});

As for $app/env/private, I think we should avoid writing arbitrary env vars to disk, since if your project folder gets uploaded somewhere for deployment (for example) that provides a potential avenue for people to steal your credentials. We can't redact unused vars until we've read the config file so we can start the app. So we would need to be very careful

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

opened #16216 to revert the snippet change

adapter: adapter(),
paths: {
origin: process.env.ORIGIN
origin: /** @type {`https://${string}`} */ (process.env.ORIGIN)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm yeah that's pretty annoying. I'm ok with this fix for now

@teemingc
teemingc merged commit 1f287f4 into version-3 Jul 2, 2026
3 checks passed
@teemingc
teemingc deleted the fix-docs-type-snippet branch July 2, 2026 14:42
@teemingc teemingc mentioned this pull request Jul 2, 2026
6 tasks
teemingc added a commit that referenced this pull request Jul 2, 2026
see #16213 (comment)

This PR changes the `paths.origin` type to `string` rather than a string
template of `https://*` so that it's easy to use with environment
variables

---

### Please don't delete this checklist! Before submitting the PR, please
make sure you do the following:
- [ ] It's really useful if your PR references an issue where it is
discussed ahead of time. In many cases, features are absent for a
reason. For large changes, please create an RFC:
https://github.com/sveltejs/rfcs
- [ ] This message body should clearly illustrate what problems it
solves.
- [ ] Ideally, include a test that fails without this PR but passes with
it.

### Tests
- [ ] Run the tests with `pnpm test` and lint the project with `pnpm
lint` and `pnpm check`

### Changesets
- [ ] If your PR makes a change that should be noted in one or more
packages' changelogs, generate a changeset by running `pnpm changeset`
and following the prompts. Changesets that add features should be
`minor` and those that fix bugs should be `patch`. Please prefix
changeset messages with `feat:`, `fix:`, or `chore:`.

### Edits

- [ ] Please ensure that 'Allow edits from maintainers' is checked. PRs
without this option may be closed.

---------

Co-authored-by: Rich Harris <richard.a.harris@gmail.com>
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 this pull request may close these issues.

3 participants