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

20 messages · Page 1 of 1 (latest)

nimble geode
#

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?

hidden eagle
#

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?

nimble geode
#

Yes, not a very complicated one but basically we just run Deno in a Docker container on Render

hidden eagle
#

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.

nimble geode
#

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

hidden eagle
#

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

nimble geode
#

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

hidden eagle
#

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?

nimble geode
#

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,
        },
      },
    });
#

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.

hidden eagle
#

wait your worker is reading internals.ts?

nimble geode
#

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 😉

hidden eagle
#

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.

nimble geode
#

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

hidden eagle
#

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";

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