Relative import from redirected url

[thgh]

There is currently a difference in behavior when importing a relative path from a remote module behind a redirect.

Deno resolves based on initial remote module URL.
Browser resolves based on final remote module URL.

Example: https://unpkg.com/example redirects to https://unpkg.com/[email protected]/cli.ts and imports ./example.ts

Deno says Cannot resolve module "./example.ts" from ".../deps/https/unpkg.com/example"
Browser fetches https://unpkg.com/[email protected]/example.ts

[kitsonk]

Oh, that is different than I thought. Deno only deals in fully qualified module names... I suspect if you did https://unpkg.com/example/cli.ts it would work. Deno intentionally doesn't work with any sort of "magic" resolution.

[ry]

Oops - I also wasn't aware browsers did this. Is import.meta.url set to the redirected URL?

In any case - this is a bug - we have to change Deno's behavior.

[thgh]

@kitsonk That works indeed. I think there is quite some magic involved in resolution in nodejs, but through unpkg it's a simple redirect.

@ry Correct, try importing https://import-meta.now.sh/redirect.js in the browser.

[hayd]

Wohoo, this also will make "registry hacking" a lot easier, i.e. deno.land/x/foo.ts can redirect to deno.land/x/foo/mod.ts

[dburles]

I ran into an issue that seems to match up here when attempting to import the neverland library.

// test.js
import 'https://unpkg.com/neverland?module';

deno test.js -r
Downloading https://unpkg.com/neverland?module...
Downloading https://unpkg.com/dom-augmentor@^0.2.8?module...
Downloading https://unpkg.com/@ungap/custom-event@^0.2.0?module...
Downloading https://unpkg.com/@ungap/weakset@^0.1.5?module...
Downloading https://unpkg.com/augmentor@^0.2.6?module...
Downloading https://unpkg.com/core.js?module... NOT FOUND
Cannot resolve module "./core.js?module" from "https://unpkg.com/augmentor@^0.2.6?module"

[thgh]

Any idea how Deno would cache a redirect on disk?

[fd]

I've been looking at this issue as well (and took two stabs at a PR).

Symlinks seem like a natural choice but it is not clear how a cross-origin redirect would be represented as a symlink. A second problem exists with the TypeScript language server which doesn't play well with symlinks.

I think the problem with the current cache is that it's loosing information about the original http responses. One way to fix this would be to always store the complete http header in a separate file along with the response (if any) much like the mime type is stored now. Deno would then have to read this header file first and then either redirect or read the body file.

dep/
  https/example.com/
    foo/
      mod.ts.header # 301 redirect "../bar/mod.ts" 
    bar/
      mod.ts.header # 200 ok
      mod.ts
  https/example.net/
    mod.ts.header # 301 redirect "https://example.com/foo/mod.ts" 

import "https://example.net/mod.ts";
// would resolve to https://example.com/bar/mod.ts

The problem with the TypeScript language server could be fixed with a plugin. But this makes the developer experience significantly worse as everyone should install the plugin (enter: npm/yarn and a node_modules dir). Maybe deno could come with it's own preconfigured language server? Or at least a language server plugin which can resolve files in the DENO_DIR.