Weird error when calling new User(...)

[ollema]

Hi again!

I am working on SSR auth for SvelteKit.

The basic idea is the following hooks.ts:

import type { Handle } from '@sveltejs/kit';
import PocketBase, { User } from 'pocketbase';
import cookie from 'cookie';

export const handle: Handle = async ({ event, resolve }) => {
	const client = new PocketBase('http://127.0.0.1:8090');
	event.locals.pocketbase = client;

	const { token, user } = cookie.parse(event.request.headers.get('Cookie') ?? '');

	if (!token || !user) {
		return await resolve(event);
	}

	client.authStore.save(token, new User(JSON.parse(user)));

	return await resolve(event);
};

then you would set these cookies, which stores the token/user, in other endpoints like /auth/login for example.

The problem here is:

client.authStore.save(token, new User(JSON.parse(user)));

I wanted to save(...) the token/user parsed from the cookies by first creating a new User with... new User(...).

However, that results in:

__vite_ssr_import_0__.User is not a constructor
TypeError: __vite_ssr_import_0__.User is not a constructor
    at Object.handle (/home/s0001325/work/sersophane/src/hooks/index.ts:15:30)
    at respond (file:///home/s0001325/work/sersophane/node_modules/.pnpm/@sveltejs+kit@1.0.0-next.411_svelte@3.49.0+vite@3.0.8/node_modules/@sveltejs/kit/src/runtime/server/index.js:202:40)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async file:///home/s0001325/work/sersophane/node_modules/.pnpm/@sveltejs+kit@1.0.0-next.411_svelte@3.49.0+vite@3.0.8/node_modules/@sveltejs/kit/src/vite/dev/index.js:396:22

---

First I thought that I might have messed up something else, so I created a StackBlitz where I:

1. Selected SvelteKit
2. Ran npm install pocketbase
3. Modified the default hooks.js function by adding import { User } from 'pocketbase'; and const user = new User();

But I still get:

__vite_ssr_import_1__.User is not a constructor
TypeError: __vite_ssr_import_1__.User is not a constructor
    at Object.handle (//home/projects/sveltejs-kit-template-default-jqt5ln/src/hooks:6:15)
    at respond (file:///home/projects/sveltejs-kit-template-default-jqt5ln/node_modules/@sveltejs/kit/src/runtime/server/index.js:217:40)
    at async eval (file:///home/projects/sveltejs-kit-template-default-jqt5ln/node_modules/@sveltejs/kit/src/vite/dev/index.js:413:22)

The StackBlitz can be found here:
https://stackblitz.com/edit/sveltejs-kit-template-default-jqt5ln?file=src/hooks.js

---

Now for the question, is this expected (maybe this is basic js and I just don't understand why this shouldn't work)?

If this is not expected, is this something that is reproducible for other frameworks or related to vite or SvelteKit (meaning I should open an issue there?)

Thanks!

[ganigeorgiev]

For some reason when in SSR mode vite seems to use the commonjs bundle even though:

• you have type:"module" in your package.json
• you are using the import/export syntax
• and the ES PocketBase bundle file has .mjs extension - https://github.com/pocketbase/js-sdk/blob/master/package.json#L12.

I'm not sure if this is a bug with Vite or something with my packaging. I'll try to find time to investigate it tomorrow. As a workaround for now you can reference directly the es bundle:

import { User } from '../node_modules/pocketbase/dist/pocketbase.es.mjs';

[ollema]

thanks!

this used to work for another user I was told, who had not updated vite/sveltekit to the same versions I used.

I would not spend too much time on this for now to be honest - a lot of moving parts with vite/sveltekit these days. might be fixed "upstream" soon

thanks for the quick reply once again!

[ganigeorgiev]

I've pushed a "fix" in v0.4.1 of the js-sdk.

Ideally, this shouldn't be needed because by spec the exports field in the package.json should take precedence over the legacy main field (this is also mentioned in https://github.com/sveltejs/kit/blob/master/documentation/faq/70-packages.md).

I'm not sure if this is an old Vite issue or a regression (they've recently seems to have added changes to the browser field behavior -vitejs/vite@85e387a) but in any case we can fix it in PocketBase by just replacing the main entrypoint to use the ES module.

Previously we were using the commonjs bundle for the main entrypoint because it was intended to serve as fallback for older node versions, but I doubt that there are users that still uses node <13 (12 reached "End-of-Life" status on 30 April 2022) so it should be a safe change.

[ollema]

great, thanks for the update