Package Name Map support as alternative to node module resolution about deno HOT 18 CLOSED

@amio Deno files are not large as you think they are...
node_modules is heavy because NPM downloads all the source code, not the bundle.
for your understanding, you can take a look at this page : )

(NPM will download 8.68MB but Deno will download only 121kB!)

from deno.

Interesting - I didn't know about that proposal. But in trying to seek a simpler module system, I would like to stick with very simple module specifiers for now (that is, exactly URLs).
On a related note: I'm struggling to decide if I should support extensionless URLs. It will make porting code much easier. On the other hand, it introduces the necessity to probe the system or remote server at multiple locations. Thoughts?

from deno.

Extensionless URLs seem to have been a net negative for node. Having to probe http/fs multiple times is a real expense if you need to optimize startup time, and it makes supporting new extensions later very difficult.

from deno.

@qti3e Eh - it seems really complex. Unlike Go, Deno just does http gets for source code - it doesn't try to clone a repo.

@TehShrike Yeah - I agree. It's unfortunate that a lot of code will have to be changed just to add an extension... but I think it's worth it - because browsers certainly are not going to do extension guessing - and it's just less code and more obvious.

from deno.

@qti3e Sure that's a huge win 🎉

While what I concern is, for a deep dependencies tree, eg:

a > b > c > d > e > f > g

Deno have to download these deps in series, rather than parallel. Roughly install time will depend on depth of the deps tree (assuming they are all same size, same network condition).

So the url-import-mechanism has pros & cons in installing speed, maybe overall it could still be faster than npm in practical.

I think npm would be the baseline for "acceptable", and fortunately npm is not fast 😅

from deno.

@amio Don't worry!, implementing parallel package loading would be straightforward whenever we do "top-level await" : ) (I don't know if Ryan is going to accept that)

I will open another issue for it.

c.c: @ry

from deno.

from deno.

Forgot to say, I do agree with this:

it should not be handled by deno

Maybe it's more like package-lock.json, it's not required, but an optimization for userland.

from deno.

@ry Actually I have an idea for that, we can use a meta-data in web pages like how go get does:

<meta name="go-import" content="github.com/ry/deno git https://github.com/ry/deno.git">

something similar for deno would be:

<meta name="deno-import" content="https://unpkg.com/[email protected]/testing.ts">

then users can do something like this in their code:

import { test } from "https://mywebpage.com/deno_testing"

from deno.

@ry oh, my main point was html meta-tag on web-pages, not the git repo.
(in my example you can see that page maps to exactly one ts file, not a git repo.)

<meta name="deno-import" content="https://unpkg.com/[email protected]/testing.ts">

from deno.

@qti3e I understood that already. That's a lot of work just to simplify linking to a file.

from deno.

@ry

On a related note: I'm struggling to decide if I should support extensionless URLs.

In the interest of web-compatibility and breaking local filesystem assumptions, I would absolutely not support this. A network fetcher just cannot do path searching like node can.

HTML currently throws if a specifiers is not a URL, or starts with /, ., or ../. This reserves the "bare" specifier space for future proposals like package name maps, but the existing valid specifiers are not going to be re-interpreted differently in the future. ./foo won't change to resolve to ./foo.js.

from deno.

@TehShrike Yeah - I agree. It's unfortunate that a lot of code will have to be changed just to add an extension... but I think it's worth it - because browsers certainly are not going to do extension guessing - and it's just less code and more obvious.

I want to point out that there's a tools-based solution here. For Polymer tooling we support node-style module resolution in our dev server and build pipeline by just rewriting specifiers. It's also possible to do on package installation. A post-install step for deno could make incompatible packages work, much like the web has had to do for years now.

Then hopefully one day not all JavaScript will be written to node's specific peculiarities.

from deno.

@justinfagnani Yeah - in the off chance Deno moves beyond the prototype stage I would invest some time in making a source rewriter for porting code.
I'll close this - thanks for the helpful discussion.

from deno.

@ry

Deno just does http gets for source code

Seems that would be painful for installing a big dependencies graph, Deno have to download the full file to collect all packages(urls) it rely on, then go on one by one deep down the whole dep graph.

from deno.

@amio True, but you only have to do that once. It could very well be that it becomes very annoying.. but I'm betting it's just a small one-time cost.

from deno.

Regarding parallel package loading i think it should not be handled by deno.

Imagine there are n number of urls that are deeply nested a > b > c > d > e > f > g, deno would handle and install these dependencies and the first time it would be slow.

Ideally we can have a script that lists all of these dependencies as urls in a flat file:

https://unpkg.com/[email protected]/index.js
https://unpkg.com/[email protected]/js/browser/bluebird.js
https://unpkg.com/[email protected]/index.js
https://unpkg.com/[email protected]/index.js

This file could then be committed and a script can be used to download them all in parallel if they are not in the cache.

This would also ideally rectify a package that requires a local within itself

For instance if I used this:

import shebang from "https://unpkg.com/[email protected]/index.js"

And this file looked like this:

import something from "./core.js"

Ideally this would have both files within the list:

https://unpkg.com/[email protected]/index.js
https://unpkg.com/[email protected]/core.js

from deno.

A deps listing file like package.json? 👍
But wait, then it should handle versions like semver, then it would becomes package.json 🤔

from deno.