Unhelpful error on property access on reactive variable that's undefined

[joakim]

Describe the bug

Svelte 5 produces an unhelpful error if:

1. A reactive variable is assigned an object whose properties are referenced in markup
2. The reactive variable gets reassigned to undefined

Uncaught TypeError: get(...) is undefined

This obscures what caused the error. A more helpful error message would be, similar to WebKit's:

Uncaught TypeError: undefined is not an object (evaluating 'foo.bar')

It can be caused by a function that usually returns an object, but may possibly return undefined, a common pattern in JS. This is the kind of bug that only happens in edge cases, making it hard to catch and reproduce.

In TypeScript, you do get a … is possibly 'undefined' error in the editor when referencing the property, and using the optional chaining operator ?. and nullish coalescing operator ?? prevents the error. Not all developers or libraries use TypeScript though, and one may have used type assertion, stopping TypeScript from detecting the type error.

In any case, informative error messages prevent headaches.

Related issue: #13619

(Thanks for your hard work on Svelte!)

Reproduction

• From $state
• From $derived

Logs

Uncaught TypeError: get(...) is undefined
    App playground:output:2870
    update_reaction playground:output:1791
    update_effect playground:output:1917
    process_effects playground:output:2092
    flush_queued_root_effects playground:output:1984
    process_deferred playground:output:2031
    schedule_effect playground:output:2048
    mark_reactions playground:output:413
    internal_set playground:output:334
    set playground:output:320
    on_click playground:output:2854
    handle_event_propagation playground:output:2512

System Info

N/A

Severity

annoyance

[Conduitry]

This error is coming directly from the JS engine, and so is going to vary across Chrome / Firefox / WebKit. Attempting to catch this, detect the specific version of if that's unhelpful, and re-throwing an error with a different message sounds like a bad idea. Adding special handling for foo.bar that first checks whether foo is undefined and throws a separate error early (before getting to the error that would be thrown by the browser) also sounds messy and also sounds like a bad idea.

[joakim]

I see. I suppose it's unlikely to occur if people use TypeScript and best practices, which is the case for most professional projects. That includes never trusting the output of untyped library functions, being careful with type assertions and using optional chaining and nullish coalescing when necessary.

I'm OK with closing this and leaving it as a reference for future searches on the error message.

Here's how it varies by browser (adopted from MDN):

TypeError: get(...) is not an object (Firefox)
TypeError: undefined is not an object (evaluating 'get(x).y') (Safari)
TypeError: Cannot read properties of undefined (reading 'x') (Chrome/V8-based)

The error message in my bug report was from Firefox.

Interesting: In Safari, the Playground's console only shows a null error message, but a nice and informative error message in the Web Inspector's console (TypeError: undefined is not an object (evaluating 'get(foo).bar')). Is that a bug in the playground?