CSS and JS file are not being generated as part of the build directory
AkashRajpurohit opened this issue · comments
Maybe this is not explicit to expressive-code but when I upgraded astro-expressive-code to 0.29.3 and astro to v4 I noticed that the calls to generated css and js file were failing to load.
The site is hosted on Cloudflare which is appending the X-Content-Type-Options: nosniff header so due to mismatch in the mime type it returns 404 response and breaks the UI for code blocks
More updates, the issue seems to be with the fact that the generated ec.hash.css and ec.hash.js files are not getting added to the _astro/ directory on the build output.
The above issue was I faced was an outcome for this since I had a custom _routes.json file and did not whitelist "/_astro/ec.sgewm.js" and "/_astro/ec.w6w22.css" file in the include list which actually makes sense because these are supposed to be static assets served from the _astro directory along with other static JS.
Will update the issue description but seems like that is the issue and adding these files to Cloudflare include list does work fine, but these ideally should not be served as dynamic endpoints.
This sounds really strange! Which version of Expressive Code did you use before your upgrade?
The dynamically generated CSS and JS files should end up in the _astro directory upon build. I even have integration test cases to ensure that.
The routes themselves generate responses using the correct content types, as you can see here: https://github.com/expressive-code/expressive-code/blob/main/packages/astro-expressive-code/routes/styles.ts
I wonder if this is an adapter issue. Are you using the Cloudflare adapter and what does your config look like?
Just for the record, during a debugging session with the Astro team on Discord we found that this upstream bug is likely to cause the issue we're encountering here:
Once the upstream bug is fixed, we'll be able to make this work here. :)
I just released version 0.29.4 that adds a prerender = true export to the injected routes to improve adapter support. However, we still need to wait for the upstream bug to be fixed so that the prerender flag actually has the documented effect.
I'm having this problem today too. Used the latest versions of Astro (^4.3.5) and Expressive Code (^0.32.4).
@hippotastic I'm not sure why it works for Starlight (Astro's documentation library) though — maybe there's some implementation there that bypasses the upstream issue you've worked?
@hippotastic the upstream issue on Astro is closed, can we re-check this? I am still seeing the generated css and js files not included in the _astro directory on build and hence being populated as valid SSR route.
Sadly the issue was only partially fixed, and the part relevant for EC is still not working.
I'm currently on holiday - if you have the time, I'd greatly appreciate if you could open a new upstream issue in case none of the existing issues matches our use case.
Will #183 fix this? 🤔
This PR might be a potential workaround until the injectRoute prerendering issue is properly fixed upstream.
However, I need to test this workaround in multiple known tricky scenarios before hopefully being able to release it, so it may unfortunately take a while until this PR can be merged.
I think the injectRoute issue is still worth fixing upstream.
Once the upstream bug is fixed, we'll be able to make this work here. :)
Just checked the upstream bug. Seems like it’s already fixed!
The problem is that the reproduction in the recently closed Astro issue uses injectRoute with an .astro entrypoint. This has been fixed indeed.
What has not been fixed yet is using injectRoute for .ts entrypoints to generate custom files. This is what EC needs to generate the CSS and JS files (which are not pages).
I was hoping that the recently closed Astro issue would fix both cases (in fact, I did not even know that these are separate cases in the Astro code and need to be fixed separately).
As soon as injectRoute prerendering for custom file entrypoints is also fixed, EC will work automatically because I already made the necessary changes on my end 20 days ago. :)
Ok, we finally fixed this using the PR from @alexanderniebuhr and some further refinements. I'll release a new version after the weekend. Thanks for your patience!
I just released this with Expressive Code v0.34.0. Thanks again!
I'll create a Starlight PR to bump the EC version there as well. The next Starlight release will probably be on Friday.
Verified that this is fixed on the new version, thanks @hippotastic