Logging url.searchParams in server load function crashes

[hyunbinseo]

Describe the bug

The following server load function fails in a Node.js environment.

// src/routes/+page.server.ts
export const load = ({ url }) => {
  console.log(url); // Works
  console.log(url.searchParams);
};

Works in a universal load function and in StackBlitz environment.

Reproduction

pnpm create svelte@latest # version 6.0.5

1. Create the above server load function
2. Launch the development server
3. Access the landing page in a browser

Logs

TypeError [ERR_INVALID_THIS]: Value of "this" must be of type URLSearchParams
    at [nodejs.util.inspect.custom] (node:internal/url:417:13)
    at formatValue (node:internal/util/inspect:805:19)
    at inspect (node:internal/util/inspect:364:10)
    at formatWithOptionsInternal (node:internal/util/inspect:2298:40)
    at formatWithOptions (node:internal/util/inspect:2160:10)
    at console.value (node:internal/console/constructor:342:14)
    at console.log (node:internal/console/constructor:379:61)
    at load (/src/routes/+page.server.ts:3:10)
    at Module.load_server_data (/node_modules/.pnpm/@sveltejs+kit@2.0.6_@sveltejs+vite-plugin-svelte@3.0.1_svelte@4.2.8_vite@5.0.10/node_modules/@sveltejs/kit/src/runtime/server/page/load_data.js:60:41)
    at /node_modules/.pnpm/@sveltejs+kit@2.0.6_@sveltejs+vite-plugin-svelte@3.0.1_svelte@4.2.8_vite@5.0.10/node_modules/@sveltejs/kit/src/runtime/server/page/index.js:143:19 {
  code: 'ERR_INVALID_THIS'
}

System Info

System:
  OS: macOS 14.2.1
  CPU: (10) arm64 Apple M1 Pro
  Memory: 56.95 MB / 16.00 GB
  Shell: 5.9 - /bin/zsh
Binaries:
  Node: 20.10.0 - ~/.volta/tools/image/node/20.10.0/bin/node
  npm: 10.2.3 - ~/.volta/tools/image/node/20.10.0/bin/npm
  pnpm: 8.13.1 - ~/.volta/bin/pnpm
Browsers:
  Chrome: 120.0.6099.129
  Edge: 120.0.2210.91
  Safari: 17.2.1
npmPackages:
  @sveltejs/adapter-auto: ^3.0.0 => 3.0.1 
  @sveltejs/kit: ^2.0.0 => 2.0.6 
  @sveltejs/vite-plugin-svelte: ^3.0.0 => 3.0.1 
  svelte: ^4.2.7 => 4.2.8 
  vite: ^5.0.3 => 5.0.10

Severity

annoyance

Additional Information

No response

[alef0gli]

You're trying to access url.searchParams directly, but you should use the 'get' method to access the value of a specific parameter.

Example:

export async function load({ url }) {
    console.log(url.searchParams.get('parameterName'))
}

[hyunbinseo]

Can't the URL's searchParams property be accessed directly?

The following code works in Node.js v20.10.0

const url = new URL('https://example.com?foo=1&bar=2');
const params1 = new URLSearchParams(url.search);

console.log(params1);
// URLSearchParams { 'foo' => '1', 'bar' => '2' }

console.log(url.searchParams);
// URLSearchParams { 'foo' => '1', 'bar' => '2' }

[alef0gli]

This solution logs in the console the result you're trying to see:

export async function load({ url }) {
    const params = new URLSearchParams(url.search);
    console.log(params)
        //URLSearchParams { 'foo' => '1', 'bar' => 2'' }
}

but if you want to retrieve the value you should treat it similarly to a map

console.log(url.searchParams.entries()) 
//URLSearchParams Iterator { [ 'foo', '1' ], [ 'bar', '2' ] }

console.log(url.searchParams.keys()) 
//URLSearchParams Iterator { 'foo', 'bar' }

console.log(url.searchParams.values())
//URLSearchParams Iterator { '1', '2' }

Check this links out to clear any doubt you might still have: https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams https://kit.svelte.dev/docs/load#using-url-data

[eltigerchino]

You really don't get anything useful from logging url.searchParams. The output will be URLSearchParams {} on the server. However, this is still a bug since kit shouldn't crash from this.

EDIT: I'm sorry. It does contain useful info

[ryanovas]

Having this bug as well, would disagree it's not useful to log all the search params. Sometimes you just wanna see what you're working with then everything crashes. Maybe it could not do that?

[wesbos]

Yeah url.searchParams should be loggable, even if it shows the iterable size URLSearchParams {size: 1}

Crashing when trying to log is not ideal, neither node nor the browser error on this.

[eltigerchino]

Thanks everyone for the persistence on this. Found a fix and it indeed does contain useful information when logged.