🦋 Changeset detected

Latest commit: 5e2b850

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

How does a compiler error look like in the terminal now?

How does a compiler error look like in the terminal now?

I don't see any difference, unless I'm missing something? I also see the InternalCompileError, which now no longer extends Error also looks fine in the terminal. Maybe it's different on Windows?

I can't check because no laptop at hand. Can you post a screenshot of a compiler error? (I think it will look a bit different, previously when a compiler error was thrown it showed the stack trace)

I can't check because no laptop at hand. Can you post a screenshot of a compiler error? (I think it will look a bit different, previously when a compiler error was thrown it showed the stack trace)

I was only checking warnings. I just noticed that InternalCompileError also extends CompileDiagnostic, which no longer extends Error so there might be some differences.

Before:

After:

To be honest, the stack trace doesn't really give the user anything as it's all internal logic anyway. So it actually looks better?

Yeah that looks better.
Wondering if that solves the original issue of the object not being properly stringified automatically (POJOs become json)

So should we merge this and close out that issue @Rich-Harris @dummdidumm?

I don't think it solves the original issue which was about the deserialization issue of the warning. With a class you don't get the pojo<->json capability

I don't think it solves the original issue which was about the deserialization issue of the warning. With a class you don't get the pojo<->json capability

We can implement a toJSON method to fix it right?

AFAIK it already has one? So it doesn't seem to work?

It works fine for me, this is it passed over postMessage:

'{"code":"mixed_event_handler_syntaxes","message":"Mixing old (on:click) and new syntaxes for event handling is not allowed. Use only the onclick syntax","filename":"(unknown)","start":{"line":5,"column":5,"character":39},"end":{"line":7,"column":2,"character":60},"position":[39,60],"frame":"3: }}></div>\\n4: \\n5: <div on:click={() => {\\n     ^\\n6: \\n7: }}></div>"}'

If we extend Error again, then it doesn't work. So I guess we've fixed it?

Ha, crazy that not extending from Error does that - that looks good to merge then