404 /@id/astro/runtime/client/astro_runtime_client_hmr__js.js.map

[kagankan]

What version of astro are you using?

1.0.0-rc.8

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

None

What package manager are you using?

npm

What operating system are you using?

Windows 10

Describe the Bug

Problem

1. start astro dev
2. access local pgae (in Chrome)
3. open devtool
4. 404 occurs

In Chrome devtool

DevTools failed to load source map: Could not load content for http://localhost:3000/@id/astro/runtime/client/astro_runtime_client_hmr__js.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

in terminal,

03:13:23 [serve]    404 /@id/astro/runtime/client/astro_runtime_client_hmr__js.js.map

Additional Notes

1.0.0-rc.4, 5, 6: 404 didn't occur
1.0.0-rc.7, 8, 1.0.0: the problem (404) occurs

Link to Minimal Reproducible Example

https://github.com/kagankan/astro-sample/tree/41c58b10d639dbdecd9b020b331fa8ee94517ebc

Participation

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

[FredKSchott]

Tracked it down to this change, only happening on Windows: https://github.com/withastro/astro/pull/4162/files

This may actually be a Vite bug, since the path itself looks incorrect and I don't think we generate that one: /@id/astro/runtime/client/astro_runtime_client_hmr__js.js.map

@natemoo-re why the URL was changed? can we change back to the way it was? @bluwy any idea why the sourcemap would be generated this way, only on Windows?

[gnublet]

I just got this on Ubuntu 20.0.4 after migrating from astro 1.0.0-beta.58 to astro 1.0.1

[bluwy]

I can reproduce this on macos too. It's because the file at /@id/astro/runtime/client/hmr.js has a sourcemap url prepended like //# sourceMappingURL=astro_runtime_client_hmr__js.js.map. In the basic example, the url doesn't get prepended though, might be a complex-enough case that's triggering it.

I am also seeing this issue for @astrojs/svelte (and likely others), e.g. http://localhost:3000/@id/@astrojs/svelte/@astrojs_svelte_client__js.js.map. Still digging in.

[bluwy]

I think I figured out how the sourcemap url got there. So it seems like when we import /@id/astro/runtime/client/hmr.js, Vite is resolving to the one in optimized deps as that module has been optimized. I couldn't find where this is specified in optimizeDeps.include though.

But I also think it's not quite right to use /@id/ in the first place. It's an internal prefix to annotate that of a resolved id path, and /@id/astro/runtime/client/hmr.js isn't the final resolved id as it would actually be resolved to node_modules/.vite/deps/astro_runtime_client_hmr__js.js instead.

Happy to chat with someone to figure out the best solution here. I did tried reverting #4162 and it worked when installing astro as a copy, not symlink.

[WintrCodes]

For reference and in case it's useful, it's also happening on EndeavourOS

[FredKSchott]

Thanks for the investigation @bluwy! It sounds like @natemoo-re didn't have a specific reason to change to /@id/..., so the easiest fix would probably be to revert that one line back to what we had before.