This is expected. Pages can override layout options, which means we can't know whether the page should be server-rendered or not without loading the +page.ts. Put the $lib/webStorage import in your +page.svelte (which will not be imported on the server, if ssr = false) instead

Put the $lib/webStorage import in your +page.svelte (which will not be imported on the server, if ssr = false) instead

Thank you for your advise, but this store was only meant as a very abstract demo of the problem I stepped over.

In my production project, I import PouchDB to get some synchronized data in offline-cases, which then controls the behaviour of my load function (PouchDB depends on localStorage and IndexedDB).
Setting up a similar project to demonstrate this behaviour, seems a little bit to much for me.

As a work around: using dynamic import() for the dependency works for me (line 15 in +page.ts).
Maybe, this "bug" should be degraded to "annoyance" with high complexity?

On the other hand: the documentation didn't tell you, that ssr is required for +page.js/ts's (in that case, it's a documentation bug)

I'm labeling this as a documentation issue. There's not really a way for this to work without trying to evaluate +page.js files on the server, which necessarily also tried to evaluate any import ... from '...'s in them. We could maybe make it clearer which files will get evaluated on the server during build and thus need to not use any browser APIs in their top-level code (not import any code that uses browser APIs at the top level).

As far as i know by now:
The only information, that decides if a +page.js/ts needs to be ssr'd is an export of ssr, right?

If so, here my thoughts:
After evaluating a +layout, with that ssr=false hint, I can slam a regex somewhere to extract that hint from child pages and layouts.
Will it be enough to avoid running/executing that file(s) in build or need svelte/kit more data, I'm currently unaware of?

That's called static analysis and it's one of those things that seems like a good idea until you try it. Let's say you try the regex approach — what do you do here?

// export const ssr = false;

Next you could try parsing the code and analysing the AST, but then what do you do here?

export const ssr = EXPERIMENTS_USE_SSR;

Maybe you could special-case environment variables like that, but what happens when you have something like this?

export { ssr, prerender } from '$lib/config';

And so on. It's tempting to say 'we could try static analysis first and then fall back to runtime analysis', but then the system becomes very hard to reason about — a seemingly unrelated change could cause the sort of failures you encountered, and it would be far from obvious how to solve them. It's much better if the rules are simple and well-understood, and in this case there are two solutions (in order of preference, but also decreasing order of ease):

• send a PR to PouchDB so that it handles the 'oh, look, I'm running in Node' case gracefully
• the dynamic import(...) approach you already landed on

I ran into a similar issue (and looking through the issues a couple of people did). I understand the rational why this can not be easily circumvented, but both "workarounds" (modify the library used, use dynamic imports everywhere), seem unsatisfying.

From my limited understanding of the internals and rational behind the design, it feels like the issue stems from having +page.ts and +layout.ts as files that mix both logic and config, which is create, if the config depends on the logic (e.g. dynamically switching ssr), but not great if the logic depends on the config (e.g. when you want to use browser only libraries with import side-effects.

A "simple" (based on my naive understanding) workaround would be to introduce a additional optional file (e.g. +config.ts) that is read first. As this config file is not the place where you are expected to put any core logic, it is easier to get rid of any problematic imports there.

An issue arises when you want to support cases, where configuration of a child route placed in +layout/+page.ts should overwrite config from a +config.ts in a parent route. As it might not be clear what to do then, but there might a couple of ways to work around that too.

The other (less granular) option, feels like to really have a global "SPA" switch. I guess most people running into this issue (myself included), were trying to build "just a simple SPA", but were surprised when suddenly code ran in a NodeJS env during dev.

Just as an additional note: It might be possible to pull that off even with the existing structure using the *.server.ts files. Basically, the only change that would be required is that if we find a ssr=false in a page.server or layout.server file, we will not load the page.ts or layout.ts file. Would that make sense in the current resolution order?

I recently encountered this problem in my project as well. Before 1.0.0-next.405, I set the global ssr to false directly in the handle function of hooks.js and it works well. But after I update sveltekit to 1.0.0-next.405, this problem arose because the render_page function of /src/runtime/server/page/index.js will try to get nodes and load +page.js files.

I understand this problem may not be easy to circumvent and I think the dynamic imports should work for me. But it's a bit strange to me that I already set global ssr to false to build "just a simple SPA" (according to AKuederle) but browser APIs is still run when build the project.