[augusto-moura]

You have to name a wildcard import:

  import * as bindingName from 'module-url'

All exports are also named, so you get an object with all exports as properties.

  console.log(bindingName.exportedName)

What is so confusing about it? The docs are also pretty clear to me: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Maybe you meant bare imports?

  import 'module-url'

In that case it only means: execute the code from that module, I don't care about importing stuff. If they set a global variable or interact with other modules I might use it.

[nick238]

As a Python dev, reading the "import * as bindingName from 'module-url'" seems confusing as it sounds like it'd try to assign multiple things to one name.

In Python, the following line pairs are roughly equivalent:

    import X
    X = __import__("X")

or

    import X as Y
    Y = __import__("X")

I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment:

    const std = @import("std");
    const parseInt = std.fmt.parseInt;

Really not a fan of languages that allow importing (using, including...) things where magic happens and a bunch of names are just available without any clear idea where from. Yeah, an IDE will help you find the source of a C function from an #include, but if you're trying to debug some 3rd party library and don't want to download the whole thing, the ability to hand-trace it a bit is just gone. Why mix a bunch of names into the local namespace? If you want short names, just assign it to a single letter variable.

Circling back to Python, the only practical place I see 'import * from ...` being used is in libraries where they are bundling up names from a bunch of submodules to be accessible at a top-level. Though, I was searching for an example of this as I know NumPy did it until they undid it: https://github.com/numpy/numpy/pull/24357

[augusto-moura]

> I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment:

That is exactly how CommonJS worked for the longest time:

  const module = require('url')

The short end of the stick was the export syntax for CJS, which is basically just assigning a property to an object:

  module.exports.value = 'foo'

The problem solve with the import syntax is that is statically parseable, you just need to parse the top-level of a package to find its dependencies. The explicit export is also a god-send for tooling, which can have a lot of introspection from it, without executing any code.