Access to script at '...' from origin 'https://www.skypack.dev' has been blocked by CORS policy

[trusktr]

I opened up the console on skypack.dev and tried

import('https://cdn.skypack.dev/@lume/element').then(console.log)

and it resulted in

Access to script at 'https://cdn.skypack.dev/-/@lume/variable@v0.2.0-hSW8g3F9MDupqncVCxtl/dist=es2020/@lume/variable/dist/dom.js' from origin 'https://www.skypack.dev' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

causing the network request to fail. The same happens no matter which domain I try it on.

[drwpow]

Strange. I’ll have a look into it, but I believe it’s only happening in Google Chrome’s console. If you look at the example on the homepage, that’s requesting https://cdn.skypack.dev/canvas-confetti straight from your browser and it’s working (you can see the request in your Network panel). Also, from any package page, you can try out any packages in CodePen too.

I believe it’s only an issue in your browser console, but I’m unsure why that is.

[FredKSchott]

I believe this happens when we return a 500, Cloudflare takes over the response and sends it’s own HTML back, without CORS.

it looks like the root issue here is the 500 that we’re returning for this package

[FredKSchott]

Figured it out: https://cdn.skypack.dev/@lume/element@0.2.3/package.json

"exports": {
  ".": "./dist/index.js",
  "./": "./dist/"
}

./ is no longer supported by Node: https://nodejs.org/api/packages.html#packages_subpath_folder_mappings

The replacement syntax is:

"exports": {
    "./features/*": "./src/features/*.js"
  },

Which encourages more specific mappings (we aren't able to optimize if you tell us every file is a valid entrypoint :)

We are landing support for subpath patterns in the coming weeks, but for now this package will work if @lume/variable adds all valid entrypoints as individual export map entry files.