deno.land/x/ corporate?
See original GitHub issueAt my company we have an internally hosted github and I’d like to introduce Deno use to the company. We can of course use urls to pull directly from our internal github and other places but that will likely put a lot of burden on github itself. What I’d really like is to run something dedicated to caching which proxies both our internal github and also public urls such as deno.land/x/. Meaning we would be able to do something like:
import { Foo } from "https://deno.internal.com/x/foo@1.0.0/mod.ts" // caches modules from deno.land/x/
import { Bar } from "https://deno.internal.com/g/bar@1.0.0/mod.ts" // caches modules from github.internal.com/...
We’re currently using Artifactory for all of our artifacts such as NPM packages, Docker images, etc. Artifactory will proxy out to npm or docker hub if you try to pull an image from it which doesn’t exist, but it also has folders we can upload things to directly… but I just do see any feature or plugin of artifactory that would work for ecmascript modules like i’m imagining here with Deno.
I’m just wondering if anyone has tried this already or knows of a solution? Before I go off and create something that already exists, I’d love to hear some ideas!
Issue Analytics
- State:
- Created 2 years ago
- Comments:5 (3 by maintainers)
Top GitHub Comments
The content-type would need to be preserved, I don’t know of a reverse proxy that wouldn’t do that by default. It isn’t some sort of Deno “trickery”, browsers require correct content-types to load scripts as well.
Not a lot of logic but just a little bit. Correct me if I’m wrong but isn’t there some functionality in Deno also related to the content-type header for typescript files as well? I guess as long as artifactory preserves those headers in its proxy requests it would work. And I agree we could live without the unversioned urls, which would simplify it.