I have a static site built with vanilla HTML, CSS. No libraries, build steps, or backend. I recently added a new feature that I use JS for. Wrote my JS in an ES module, linked to it (<script src="..." type="module"></script>) in my HTML document <head>. Everything worked as expected when testing it locally, and in a branch deploy preview. When I merged the branch into master, the new code deployed, but the ES module is not loaded. Firefox throws 2 errors in the console…
I have read through that doc, and I’m not exactly sure what you are proposing. The only thing I can think of is setting the Access-Control-Allow-Origin header in the headers section, but this is a problem because if I set it to nicolaos.dev (my origin in production) then it will break my per-pr (netlify.com) and local (localhost) builds. According to the docs…
Redirects and headers are GLOBAL for all builds – they do not get scoped to contexts no matter where you define them in the file.
And no, I’m not setting it to * as this is not a good security practice unless it is meant to be a public resource.
I can’t be the first one to experience this, loading a javascript file via a script tag is literally one of if not the most common pieces of web development. This is very frustrating.
Quick correction, the JS file which is failing to load is not the one linked to in the <script> tag, but a second module which is imported by the module loaded via the <script> tag. It seems like netlify is not hosting this secondary module on my origin, but it’s trying to access via the cloudfront.net one, which is causing the CORS error since the page making the request has an origin of nicolaos.dev. Any chance this is the result of having the pretty_urls = true option set in my netlify.toml?
Hi, yes, if you have pretty_urls enabled it also enabled post-processing which causes your assets to be hosted on cloudfront. If you are getting CORS issues, you may need to disable post-processing completely. Hope that helps.
@Dennis thanks for the explanation. Disabling post-processing did fix the issue. Though I don’t understand why the first JS file referenced in the <script> tag loaded without CORS issues.