CODEWITHSUNDEEP
typescriptsvelte
Peter Toth
Peter Toth

Reputation: 770

Getting ambiguous errors with svelte | ReferenceError: Utils is not defined

I am wondering what are the best practices for debugging svelte applications. Most of the time I'm getting extremely ambiguous errors, or something referencing the compiled site.

This has lead me to find working with svelte rather stressful. Though I am maybe just doing it wrong?

Anyways, I started off from the official svelte ts degit template: https://svelte.dev/blog/svelte-and-typescript

and just as the detailed in the documentation I did:

npx degit sveltejs/template svelte-typescript-app
cd svelte-typescript-app
node scripts/setupTypeScript.js

And after making 2-3 components, I'm getting the following console error, my IDE shows nothing wrong (VSC with svelte plugin):

Uncaught ReferenceError: Utils is not defined
    at main.ts:5:2
(anonymous) @ main.ts:5

Now this is pointing to the main.ts file, let's see what's in it:

import App from './App.svelte';

const app = new App({
    target: document.body,
});

export default app;

Well, no Utils for sure and after browsing around the svelte docs, the App component shouldn't even take an argument named 'Utils'.

What am I doing wrong, how to fix it and how can I debug better with svelte.

Upvotes: 0

Views: 754

Answers (2)

Aurther
Aurther

Reputation: 41

Check if your VSC has not injected an unwanted import statement in script section in any component...I had same issue until I discovered VSC had, for some reason, auto inserted code below

 import { identity } from 'svelte/types/runtime/internal/utils';

Upvotes: 0

brunnerh
brunnerh

Reputation: 184516

Svelte does a lot of things internally, so one line of source can correspond with many lines of compiled output. This sometimes makes relying on errors referencing the original source not a viable option.

If the error references something you do not recognize, look at the actual compiled output running in the browser. Depending on what browser you use, you may have to disable source maps to have stack traces point to the real error site. I have them turned off most of the time because of how unhelpful they can be.

You may then also be able to stop the debugger on error so you can inspect the current state of the scope and see what is being referenced and read.

Upvotes: 1

Related Questions