Stacktrace reports wrong line number

[truesri]

What version of astro are you using?

1.6.10

Are you using an SSR adapter? If so, which one?

None

What package manager are you using?

npm

What operating system are you using?

Mac

Describe the Bug

When accessing data that is undefined the stacktrace reports the wrong line number. When using no integrations the line number seems to be off by 1, but when using the tailwindcss integration it is off by more.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/github-vdxjk2?file=src/pages/index.astro

Participation

• I am willing to submit a pull request for this issue.

[dsomel21]

@bluwy, are we sure that this is a p3 ("An edge case that only affects very specific usage").

It was happening to me in #6372 when I was basically doing:

---
const response = await fetch(
  "https://clean-dragons-hear-198-54-132-72.loca.lt/api/v1/books"
);
const data = await response.json();
const book = data.books.find((b) => b.id == id); // This is breaking cuz the fetch failed
---

Nothing too specific.

I can look into it, but can you share some details about where to look (is it the astro repo, or what).

[JoshuaKGoldberg]

It this an appropriate place for me to suggest this be raised to a p2? I agree with @dsomel21, it's really quite a poor onboarding experience for folks like me new to Astro.

I'd love to look into helping fix this if you can give a few starting pointers 🙂

[Princesseuh]

It this an appropriate place for me to suggest this be raised to a p2? I agree with @dsomel21, it's really quite a poor onboarding experience for folks like me new to Astro.

I'd love to look into helping fix this if you can give a few starting pointers 🙂

Sorry for the late answer, I didn't see your comment. The causes of this are quite various, so it's generally hard to pinpoint the problem and give guidance.

In most cases, apart from CSS errors, the reason is source map related, either the source map that our compiler generated isn't accurate, or the source map isn't linked correctly / configured correctly.

For frontmatter errors in particular, there's a bit of a special situation where the frontmatter is reparsed to give a better error message: https://github.com/withastro/astro/blob/72c6bf01fe49b331ca8ad9206a7506b15caf5b8d/packages/astro/src/vite-plugin-astro/compile.ts, which I feel might be partially responsible? I'm not sure.

For CSS, generally the problem is that due to how the processing is done, we lose the original position of the style tag. We try to guess it, but it fails in most cases. I'm not 100% sure what we could do there, perhaps the compiler could return some positions as well

Regarding the priority of this issue, we definitely recognize that it's a bad experience for users to have errors on the wrong lines! 😅 However, since this is not build breaking and is quite a fair amount of work, it unfortunately naturally falls behind more pressing issues. I'll bump it to p4 nonetheless, I think we have the bandwidth to fix this..

[bluwy]

I looked into this over the week and it's quite a rabbithole. Things I've uncovered:

1. The tailwind integration causing worser line offsets is caused by astro:scripts:page-ssr. I think MagicString isn't outputting the right sourcemap when using prepend with \n.
2. Vite's SSR rewrite seems to not rewrite some paths to the right source (Fix error stacktrace from Vite SSR runtime #7273)
3. Vite's combineSourcemap implementation seems to generate an incorrect sourcemap, particularly this line. Which means there might be a bug in remapping?

I'm testing with https://evanw.github.io/source-map-visualization/ for those who want to debug this. Overall I think the issue lies in Vite, but this also only covers the issue's original repro. I haven't checked the others yet.

[kireerik]

This would be very useful. I could add class name labels in development mode (related discussion: emotion-js/emotion#2172 (reply in thread)) if this works properly.

related example:

• Refo

 
current workaround:

• getModuleName.js

• style/css.js#L20

[bluwy]

This issue's repro and the CSS error repro (#6971) should be fixed in #7273 and #7491 respectively. Not sure if that's all the issues to be able to close this?

[remorses]

You can now use https://github.com/antfu/vite-plugin-inspect to inspect source maps issues (even in SSR code)

Screen.Recording.2023-06-28.at.11.25.35.mov

[bluwy]

Oh schnap that is super helpful! Thanks for sharing and making it happen!

[remorses]

I deubugged the sourcemaps with the inspect plugin, the insividual sourcemaps for the astro files are correct, the issue must be in the way they are applied to the stack trace or maybe combined

[bluwy]

Are you using the latest version of Astro? It should fix the stacktrace numbers (with Vite) and uses hi-res sourcemaps so the merged sourcemap isn't degraded.

[remorses]

2.7.2 works 🎉, i was using 2.7.1

Edit: tested with the repro on this issue

[kireerik]

With my use case the line numbers are still wrong.

[bluwy]

@kireerik can you provide a repro for your usecase? I don't quite understand how it's related to Astro.

[kireerik]

Sure:

• Refo

 
If I emit an Error on this line for example:

• example/index/style/css.js#L23

Then I get incorrect line numbers with the Error for example for this function call:

• example/index/index/site/main/header/index.jsx#L17

I would need the correct line number (I would expect 17 in the above case (for that file)). So I can then import for example the header component module as raw and based on the correct line number extract the variable name (Header in the case of the above example) and set that as a class name label (in development mode).

[bluwy]

@kireerik that's not a reproduction. https://antfu.me/posts/why-reproductions-are-required

[kireerik]

I have created one for you:

• https://stackblitz.com/edit/github-tdgy2y?file=index%2Fstyle%2Fcss.js,index%2Findex%2Fsite%2Fmain%2Fheader%2Findex.jsx

[bluwy]

@kireerik Sorry for the late reply. I just checked your repro, and what you're trying to do is unfortunately not something supported by Vite currently. Vite needs to transform SSR code in a different way for it to work, and that transformation affects the stacktrace generated from new Errro().

While Vite tries to fix it, it can only fix for thrown and caught errors. The console.log(new Error()) is simply creating an error and consuming it itself. So there's no way for Vite to intercept it. I'd suggest finding another way to achieve what you're aiming for. Acquiring the stacktrace this way isn't always safe.

I'm going to close this as we haven't got any new reports so far. And new ones should be created as new issues.