Add "import *" like Python

[cnshenj]

Sometimes a class/function has a few supporting small types, like the example below.
In foo.ts:

interface IOptions {...}
interface IResult {...}
function foo(options: IOptions): IResult {...}
export = foo;

Then in another file:

import foo = require("foo");
var options: IOptions = {...};
var result = foo(options);

This doesn't work because IOptions and IResult have be exported too. But then you'll have to write:

import fooMod = require("foo");
var options: fooMod.IOptions = {...};
var result = fooMod.foo(options);

It's also possible to put IOptions and IResult in separate files. But those two types are small and tightly coupled to foo, so it's easier to maintain them in the same file as foo. Also, you'll need to write 3 import statements to import them all.

Why not support the following (like Python's from module import *)?
In foo.ts:

export interface IOptions {...}
export interface IResult {...}
export function foo(options: IOptions): IResult {...}

Then in another file:

import * = require("foo");
var options: IOptions = {...};
var result = foo(options);

[mhegazy]

With ES6 module syntax support you can write it as:

import  { foo, IOptions } from "foo";
var options: IOptions = {...};
var result = foo(options);

[cnshenj]

Seems the ES6 module syntax is only supported by TypeScript 1.5, which is not released yet?

[mhegazy]

TypeScript 1.5-alpha has been released, see https://github.com/Microsoft/TypeScript/releases/tag/v1.5.0-alpha for more details.

[nippur72]

@mhegazy but you still have to provide a list of names/aliases which is annoying if you have a file with lot of definitions. Instead it would be very useful to support a * syntax like this:

import { * } from "file";

Ideally the best syntax would be:

import "file";

but as I see from #2242 it's already taken for "Bare Imports".

Allowing import of whole files is a well established pattern (for example) in the Dart language.

[mhegazy]

The only issue with import * from "file" is it breaks single file transpilation scenarios. and prevents modules from being statically-analyzable, one of the design vectors the committee stressed.

[nippur72]

@mhegazy it doesn't have to be different from what TypeScript is actually doing now.

To be more clear, my suggestion is that:

import { * } from "file";      // notice curly braces

to became a shortcut for

import { foo,bar } from "file";

Its only purpose should be to avoid to re-type names; it should not introduce any new behaviour.
In other words, it would scan "file" looking for exported symbols and put in place of the *.

[teppeis]

@nippur72
As @mhegazy mentioned, it breaks single file transpilation scenarios.
TypeScript should use ES Modules spec syntax. It considers most of scenarios.

[nippur72]

@teppeis if import { * } breaks single-file-transpilation scenarios, then import { foo,bar } does too (assuming that * would be replaced by the list of exported names). What am I missing?

[mhegazy]

The idea is that you can process a module in isolation, without knowing anything about other modules..

in cases where you want the compile to bring all bindings in scope using import * from mod" this is not possible. consider:

import * from "mod1";
import * from "mod2";

a;

we do not know if a referes to mod1.a or mod2.a, or a global a. the only way the compiler can resolve these is by understanding all exported bindings from mod1, mod2, and the global scope. thus breaking single module transpilation..

i understand this is a useful feature, TypeScript already supports something similar with namespaces where nested namespaces do not need to fully qualify access to exported members. However, breaking the module transpilation would block a large set of tools and workflows that other users find useful.

[nippur72]

@mhegazy thank you for the example, now it's more clear what is meant by "breaks single file scenarios".

If the goal is avoiding scanning external files, then it makes sense to be forced to explicitly list names.

[kitsonk]

If the goal is avoiding scanning external files, then it makes sense to be forced to explicitly list names.

How do you scan files when you are transpiling client side? It isn't a goal, it is a technical reality in some environments.

[mhegazy]

As mentioned in #2819 (comment), the original issue should be handled by ES6 module syntax.