Probably not, but Deno has Oak, which is Express-like and the combination of those two will get you close. But most node libs are not compatible and similarly node projects.
Will give it a try, really curious how importing works and all.
So was I, so this is what I determined, on top of the official docs.[1]
On deno run of a script, it will download referenced imports and put them into a cache directory with a hash of the name. On a UNIX-like, this seems to be in ~/.cache/deno/deps (there's also a ~/.cache/deno/gen for the TS to JS stuff). Subsequent runs do not seem to download the scripts, but instead use the cached hashed versions. There's probably a way to blow out or overwrite the cache with newer download with a deno command, but I'm not sure what it is.
Compiling bundled the cached dependencies, so they aren't downloaded on run. Importing from local files is also possible, as noted in the docs I linked.
I'm happy to be corrected to supplemented on any of that info, I would rather know the actual way it works than persist in a slightly wrong assumption. :)
One of Deno's objectives is not to expose V8 internals, so node packages relying on those will be harder to port
And this is not a obscure need. There are cloud providers who let you run JS on a specialized and restricted API.
However, there is nothing stopping you from using Node or integrating V8 and go wild with it! (In fact I would argue that this is a solid strategy for some types of projects, where you can get the best of both (static/dynamic) worlds.
Sounds rather obscure actually. Still somewhat confused why this would be useful in Deno. Looks like it's just a repeat of what happened with Java's SecurityManager, which is now being deprecated and removed.
It is how cloudflare workers work