The issue is that JavaScript (by extension TypeScript) doesn't have the concept of folders.

You can only import a single file per import statement.

Developers create "barrel" files that allow them to re-export all of the important stuff in a folder externally. This allows for namespacing

  // foo/index.ts
  export * from './foobar'


  // main.ts
  import * as foo from './foo/index'

  new foo.Foobar()

Or use destructured imports to help with static analysis tool that trace imports removing unused references from the final build

  // main.ts
  import { Foobar } from './foo/index'

Node has non standard behaviour where it appends `/index` to the import path if it's a folder allowing you to shorten imports to

  import {} from './foo'

Gotcha in ES6 import is that you need to import the default export specifically eg. import default as Foo, * as Bar

It would be much easier if it was one namespace like in Node.js require. eg. var Foo = await requires("foo", {fs: "/home/user"})

Node.js modules are pretty much perfect besides the security flaws.

Yeah I am sad that ES6 imports don't allow for easy namespacing.

You can get around this with a double barrel. In the outer barrel, export your individual things

   // index.barrel.js
   export * from './foo.js'

Then in your main barrel re-export them under a namespace

   // index.js
   export * as foobar from './index.barrel.js'

Then from you application you are forced to have a named import with the namespace defined

   // main.js
   import { foobar } from './foobar/index.js'
   
   foobar.foo()

You can submit a proposal to introduce namespacing to ES6 imports

I found most of the dependency woes to go away with import maps: https://deno.land/[email protected]/linking_to_external_code/imp...

it seems like libraries can't use import maps though, right? the final binary can provide that flag, but is there a way for library dependencies to specify their own import maps? the spec [1] has support for scoping, but I didn't see a way to integrate that with the Deno loader.

[1] https://github.com/WICG/import-maps#scoping-examples

Yeah, libraries can't use import maps because import maps are not extensible

It's almost like you need something to manage your packages to generate them.

oh damn, that's exactly what i've wanted.

Except you have to make them manually. They could've trivially built a thing that takes your npm package.json and converts it to an import map internally, but instead you gotta manage all that hassle yourself because they don't want to play nice with npm. /rant

This is probably one of the bigger issues holding me back from adopting Deno (at least for personal projects anyway). I'm sorry, I don't want to go back to early 2000s where we're copy pasting random links to script tags. Those days are over and for the better. NPM has proved pretty much undeniably that people prefer the simplicity of just typing in the name of something to install it, and import it. Does it have issues? Absolutely. I'd rather those issues be resolved than completely throwing away the concept though.

This feels to me a bit like if a new browser came around and said "DNS is the root of all evil" and only allowed you to directly type in the IP address of websites.

You can make all kinds of excuses, like "oh, but you can keep a list of your own!" or "hey, you can install this plugin that gives you DNS lookups back", but ultimately as a user I'm gonna say "No thanks, I'll keep using a browser that doesn't needlessly complicate my day."

I'm usually an early adopter for this kind of stuff, and I really like a lot about Deno, which is why this situation just makes me very sad.

This 100%. Every time it comes up I'm just saddened by the fact that they're so antagonistic towards the existing npm ecosystem, when those problems could be so easily solved and their userbase so easily expanded with some minor compatibility tooling that allows importing npm packages.

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";

> 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.

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.

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.

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.

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.

Wouldn’t this work?

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

This isn't valid syntax, no

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

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.

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.

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

No they can't, Deno is JavaScript compliant

If dependencies are imports from URLs, how does one audit their dependencies?

If a server gets hacked those TS can be replaced with malicious versions.

In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release.

Does demo generate some type of file that keeps a hash of all downloaded imports to verify against the next time those imports are downloaded?

Integrity checking & lock files https://deno.land/[email protected]/linking_to_external_code/int...

The same problem (and solution: package-lock.json or yarn.lock) exists in npm if you use semver version specifiers, or npm itself could be hacked, it’s just a bit more acute in Deno since it’s easy and common to load files from arbitrary hosts that don’t enforce immutable versions.

npm has a lot more to lose from being hacked than some random URL, I trust npm with my packages because they fix stuff when something like left-pad happens, the same is not true for every URL I'd have to import to build a deno package.

> In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release.

This is only true as long as you trust NPM. If they were hacked or taken over by a malicious actor, packages could be modified unbeknownst to you.

No they could not. Because your package-lock.json contains integrity hashes that are verified during installation.

Only if you update dependencies, a fresh install would not have such integrity checks, so it's just as vulnerable as Deno hosts to such attacks

Not sure I’d use the local deps file. I really like just the import {..} from “https://xn--ivg. The version, everything, is up front and explicit.

The problem the deps.ts pattern solves is that your project has several dozen modules that all import a particular version of a dependency, and now you need to update them all to a new version of that dependency.

(If your project only has one module, then you don’t have this problem and don’t need this solution.)

Why not just use sed?

Why bother with DRY at all? Just sed all day to replace 24 instances of function foo().

Indeed, DRY is overrated, especially for trivial things like string constants.

How is DRY overrated? Making edits to a codebase shouldn't require any more tools than a text editor. I wouldn't want to live in a house that required powertools for every minor repair, it would be burdensome and indicate poor development practices.

Are you using a text editor that can't index your repo and do search-replace within? Vim and emacs both do this easily.

If you're not using an IDE, have you considered that by DRY-ing up constants, you're adding about 2-3 steps to even see what the value of a constant is?

Jump to the top of your file, figure out where the import is from, open the other file, then find constant name.

You also force your code reviewers to do this in e.g. GitHub, where there's no convenient 'jump to definition'.

IMHO, if your starting point is that you won't use sed, can't use a good IDE, and won't configure your editor nicely, then you're just creating a lot of unnecessary work for yourself, regardless of whether you're doing DRY.

Power tools are appropriate if you're building a house.

You're just going to wind up making changes where you don't need them that way. There's no guarantee that because the code looks the same it does the same. An IDE can't figure out what side-effects will happen.

By just letting your IDE make changes globally, you're running the risk of introducing bugs. By DRYng up your code, you know that the change you make will have the same result everywhere.

You could opt to improve upon the standard practice, right? I have only played with Demo a little, but the deps file seems only like a convention rather than a strict rule.

Why not instead create a deps directory, and keep in it one file per dependency? Inside each file, you re-export the library from URL.

This way you can import from files rather than URLs elsewhere in your code, and it should be clear which dependency is being imported from the file name itself.

That solution is great! But it sounds like something that could be automated or managed for me.

i like to have multiple deps files roughly grouped. this reduces not only the likelihood of name clashes but also gives a bit more structure and in addition when running in the browser its possible to handle bundling the dependencies separately by that grouping.

You realize Deno is founded by Ryan Dahl, who founded Node 12 years ago, don't you?

Perhaps you should be less quick to label anything about it "asinine" or even "awful hack".

With all respect to Ryan Dahl, I'm sure he'd disagree with the "asinine" characterization but would also disagree he's infallible - as evidenced by the creation of Deno after Node

I'm just saying Don't be so quick to judge. Be humble!

No one is infallible. That said, creating Deno after Node doesn't imply that Node was a fail or that Deno will be perfect. Obviously not.

Consider that someone really smart has reasons for doing (or trying to do) things a certain way. Be humble!

Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style.

Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857

Just take a look at a random stdlib source file: https://github.com/nodejs/node/blob/master/lib/readline.js

``` if (input && input.input) { // An options object was given output = input.output; completer = input.completer; terminal = input.terminal; history = input.history; historySize = input.historySize; signal = input.signal; ```

It's junior-level code writing all over the project. That is a failure in my mind, especially when I know the library backing my project has to import all that junk hidden from view.

See (wontfix) fs.promises.readFile is 40% slower than fs.readFile: https://news.ycombinator.com/item?id=26332774

Not to mention the awkward political nature. There is a BLM banner on their front page: https://nodejs.org .The founder of BLM, Patrisse Cullors, just bought 4 mansions, the last for $1.4 Million USD: https://news.yahoo.com/blm-official-calls-investigation-foun...

Node's dev team is not interesting in supporting the community. They are amateurs who are trying to be woke and add "top Node contributor" to their toolbelt of proverbial ego items. Prove me wrong.

Always snopes before you post! https://www.snopes.com/fact-check/patrisse-cullors-topanga-h...

The "mansion" is a 3br 2ba, real estate is just kind of expensive in LA. My Bay Area home is actually worth more than that, and I don't see why she shouldn't be allowed to make real estate investments or have a nice-ish house. There's no evidence any funds have been misappropriated, and if it comes to light I'll join you in complaining, but until then it just kinda sounds like an attempt to discredit BLM-the-movement by discrediting it's leaders and organization without any real evidence.

Snopes is a great source! /s https://www.dailymail.co.uk/news/article-4730092/Snopes-brin...

https://www.boston25news.com/news/trending-now/snopescom-cof...

https://en.wikipedia.org/wiki/Snopes

"Kids, say no to Snopes!"

Most support BLM the concept, few know anything of BLM the organization.

The movement has been co-opted by opportunists just like Al Sharpton did 10 years ago.

Police reform is an issue that everyone can get behind. But it's not as catchy and divisive.

I do! And I think node has a lot of flaws (Ryan seems to agree).

I do not understand why deno has gone for this route. It seems primed to produce a package manager eventually, and it seems like a bad idea to leave package manager creation down to whoever makes the first decent tool (which is mostly why npm is the standard for node.)