tmcw•16mo ago

Can I pre-cache dependencies that I specify using npm:?

Hi! Trying to figure out the right way to combine Deno's module support to make our deploys consistent. In particular, I was using esm.sh URLs, but just hit some CDN errors so that made me switch to npm: in hopes of it being more reliable. But afaict deno vendor doesn't vendor npm dependencies? What's the right combination of things to do to deploy reliably?

14 Replies

ioB•16mo ago

Currently, esm.sh is the recommended way of doing things for deploy. I'm assuming you have your own build pipeline for deploying your apps?

tmcw•16mo ago

Yes, not a very complicated one but basically we just run Deno in a Docker container on Render So esm.sh + vendoring?

ioB•16mo ago

That would be the recommended way of doing things if you need npm deps. Depending on what libraries you're using, there are often very good Deno alternatives so it might be worth looking into those.

tmcw•16mo ago

for the particular things we're using, they're mostly very niche, hard-to-replicate projects like comlink, superjson, magic-string

ioB•16mo ago

Huh, interesting. Have never heard of those libs but outside of comlink, superjson and magic-string should "just work" with Deno? Comlink might do some node-specific stuff that makes stuff challenging

tmcw•16mo ago

They all work with Deno just fine, I don't think I need them to run in nodejs mode. I'm really just trying to figure out what's the way to deploy without relying on a CDN being functional esm.sh + vendor seems like the way? Ah, using vendor triggers some different permissions. That's why I wasn't using it. Sorry, this codebase is a little zany - we're using WebWorker's ability to run with reduced permissions, so there's a catch-22 where if I vendor dependencies, then Deno tries to use vendored deps within the WebWorker, which doesn't have --allow-read. Maybe there's a way to exclude stuff from being vendored

ioB•16mo ago

then Deno tries to use vendored deps within the WebWorker, which doesn't have --allow-read

Sorry I'm confused by what you mean by this?

tmcw•16mo ago

So like we have this code:

    worker = new Worker(new URL("./worker.ts", import.meta.url).href, {
      type: "module",
      deno: {
        permissions: {
          read: ['internals.ts'],
          net: true,
        },
      },
    });

    worker = new Worker(new URL("./worker.ts", import.meta.url).href, {
      type: "module",
      deno: {
        permissions: {
          read: ['internals.ts'],
          net: true,
        },
      },
    });

So worker.ts can't read any files except for what's in internals.ts. Maybe I just need to give it read access to vendor too.

ioB•16mo ago

wait your worker is reading internals.ts?

tmcw•16mo ago

Yeah - though to be clear, it's just a file named internals.ts, I think Deno has a file with the same name, it's not that file 😉

ioB•16mo ago

Sorry, just double checking, you're doing something along the lines of Deno.readTextFile and not just importing the file right? I think adding permissions to read the vendored file(s) would be the workaround for this. Definitely an interesting project setup.

tmcw•16mo ago

it's importing from internals.ts, but that's the only local import the worker has access to (is the intent)

ioB•16mo ago

I don't know if one can limit static imports? I assume you mean that your worker starts with something along the lines of

import "./internals.ts";

import "./internals.ts";

what are you using web workers for? Wondering if there's something that I'm not understanding.

tmcw•16mo ago

evaluating untrusted user code - it's basically sandboxing, and the worker is the most inside level of the sandbox