[Soremwar]

You do something like this

  export * as Oak from "https://deno.land/x/oak/mod.ts";
  export * as Postgres from "https://deno.land/x/postgres/mod.ts";

Then you do this:

  import { Oak, Postgres } from "./deps.ts";

[zkldi]

> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?)

I know you can do this, but then you can't do

    import { Function1, Function2 } from "oak";

You could do

    import { Oak } from "./deps.ts";
    const { Function1, Function2 } = Oak;

But that is still an awful workaround.

[antihero]

Perhaps you could do:

     import { Function1, Function2} from "https://deno.land/x/oak/mod.ts";

In the file that needs them? Though then you have a lot of redundant URLs everywhere and god knows how auto-imports could work.

Or perhaps you could do

    // deps/oak.ts

     export * from "https://deno.land/x/oak/mod.ts";

and then you'd do

    import { Function1, Function2 } from './deps/oak';

I am not a fan of any of these.

[searchableguy]

There are user land tools to manage dependencies for you. I cannot comment on the specifics because I haven't used them extensively but one example is deno-udd.

It updates your dependencies. https://github.com/hayd/deno-udd

There are one or two more feature rich ones. The need for deps.ts can be eliminated with management tools which work with your imports directly.

[zkldi]

That's just a package manager!

If something like that is needed, then I think deno should attempt to come with something for managing dependencies.

Eventually, developer convinience will win, and everyone will settle on some sort of package manager for deno. It'd probably be for the best if deno made it official as, personally, I think this is heading towards a second NPM.

[searchableguy]

Not quite the same. It's a simple management tool which rewrites your imports to use the latest version from supported registries. Deno binary still handles all the resolution, fetching, caching and loading.

There are no plans to add such convenience in the binary because it would mean limiting places you can import from (cannot upgrade deps for unsupported registries). Deno binary will remain agnostic to where you import from.

Community will come up with something if it's a huge problem and settle eventually.

[sroussey]

Wouldn’t this work?

import { Oak: {Function1, Function2} } from "./deps.ts";

[joelg236]

This isn't valid syntax, no

[jessaustin]

This is a regression. This was possible with "require" and destructuring assignment.

[goldenkey]

I don't know why you are getting downvoted. I agree. The difference is that ES6 imports are meant to be more optimized and also can allow for async/top-level async modules. I believe part of the additions of ES6 modules made it harder to treat the right hand side like a complete object that can be destructured. In summary, it's not the syntax, it's the difference in feature richness between ES6 and CommonJS importing.

[jessaustin]

Yeah, I'm not saying that import was a mistake or even a good idea done in the wrong way. I use "import" whenever I can in my own code. It could be impossible to import only the particular things one needs, and that trusting tree-shaking is the best we can do. However, it very much seems like a first version to me, and that import statements could be made smart enough to destructure.

[sroussey]

Yeah, was afraid it might be bad ES6. But this is Delo, so they can do whatever they want.

[Soremwar]

No they can't, Deno is JavaScript compliant