tmcw
tmcw16mo 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
ioB16mo 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
tmcw16mo ago
Yes, not a very complicated one but basically we just run Deno in a Docker container on Render So esm.sh + vendoring?
ioB
ioB16mo 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
tmcw16mo ago
for the particular things we're using, they're mostly very niche, hard-to-replicate projects like comlink, superjson, magic-string
ioB
ioB16mo 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
tmcw16mo 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
ioB16mo 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
tmcw16mo 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
ioB16mo ago
wait your worker is reading internals.ts?
tmcw
tmcw16mo 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
ioB16mo 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
tmcw16mo ago
it's importing from internals.ts, but that's the only local import the worker has access to (is the intent)
ioB
ioB16mo 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
tmcw16mo ago
evaluating untrusted user code - it's basically sandboxing, and the worker is the most inside level of the sandbox