502 (Bad Gateway) when importing from esm.sh in Deno

Questions / Help Build debugging
1

In my test Deno app to try Fly out, I’d like to use a module from esh.sh (using a deno.lock file to be sure it’s the content I expect), but it just won’t “fly” as it were: The import causes a 502: Bad Gateway error. The esh.sh module is https://esm.sh/@planetscale/database@1.8.0. This works just fine locally and in Deno Deploy, it’s specific to Fly.

It’s entirely consistent, making me wonder if there’s some setup issue between Fly and esh.sh…?

Interestingly, I can read the module text from esm.sh using fetch in my Deno code (though that isn’t a workaround). The module I’m reading is importing other modules also from esh.sh, which may be why the read works (I’m just reading the first module) but the import doesn’t.

Thanks,

– T.J.

3

Okay, I’ve figured this out and it isn’t a Fly.io problem. It’s a Deno / esm.sh problem.

I debugged this more today to see if A) It was a transient problem (it wasn’t), and B) To get to the bottom of it if possible. Digging through the Monitoring tab, I found an error loading the Planetscale module because it didn’t match the hash in deno.lock. And there’s a good reason for that: The content changed.

As I write this, getting https://esm.sh/@planetscale/database@1.8.0 returns this:

/* esm.sh - @planetscale/database@1.8.0 */
export * from "/v128/@planetscale/database@1.8.0/esnext/database.mjs";

…which in turn makes Deno load https://esm.sh/v128/@planetscale/database@1.8.0/denonext/database.mjs.

But, my local workstation Deno cache for https://esm.sh/@planetscale/database@1.8.0 contained this instead:

/* esm.sh - @planetscale/database@1.8.0 */
export * from "/v127/@planetscale/database@1.8.0/esnext/database.mjs";

Note the v127 instead of v128, despite the original URL being for a specific version (@1.8.0). :frowning: The content changed without the URL changing (which is what deno.lock is there to protect us from).

Removing the cache entries for https://esm.sh/@planetscale/database@1.8.0 (and anything else with @planetscale) and rebuilding the deno.lock updated the hash, and the module load worked on Fly.

So why did the content change? Because of versions of esbuild apparently. :confused: From the esm.sh FAQ:

Why I get The source code is invalid... error in Deno?

Since Deno 1.18+ will generate the deno.lock file for the dependencies, but esm.sh builds code with different version of esbuild when you imports modules from different build version. To fix this issue, please try to pin the build version like https://esm.sh/react?pin=v128. Or use the CLI Script to manage the dependencies that will fix the build version automatically.

So that’s the answer, and the solution would appear to be to use their CLI script. (Or not use esm.sh.)