allow type 'unsafe' way to doing es6 style imports

[pdeva]

Currently if have an import of a library which doesnt have any type definition, like this:

import {A} from 'randomLib';

Typescript will mark an error saying it cant find randomLib anywhere.
We need some way of telling typescript to suppress the error for this particular import.

[DanielRosenwasser]

I think the solutions and discussion in #2709 covers this scenario.

[DanielRosenwasser]

Though, the way you should be fixing this is by declaring the module itself:

declare module "randomLib" {
    export let A: any;
}

[pdeva]

this is not feasible for large projects.

now for every library we want to use we have to manually create the
typedefs.

kinda defeats the whole 'superset of JavaScript' message.

On Tuesday, January 5, 2016, Daniel Rosenwasser notifications@github.com
wrote:

Though, the way you should be fixing this is by declaring the module
itself:

declare module "randomLib" {
export let A: any;
}

—
Reply to this email directly or view it on GitHub
#6371 (comment)
.

Prashant

[DanielRosenwasser]

I agree, this is extremely frustrating for people who are migrating.

Tangentially, what libraries are you trying to use that don't have typings? Just curious.

[RyanCavanaugh]

This came up during the migrate-a-thon as well. The long tail of libraries is surprisingly long.

[ivogabe]

I don't think #2709 wouldn't be the best fix for this issue. When you've got typings for a library later on, you would need to remove : any from all your files. Declaring a weak version of the library would make it easier to migrate later, but it's too much work to create it. I think an easy way to create declare a module, without saying anything of it's content, would be the best solution. I'm thinking on something like this:

declare module "foo";
declare module "bar";

After declaring these modules in a .d.ts file, you can use these modules like you would expect. All kinds of import statements are allowed (legacy, named and default imports) and you won't get type errors. What does everyone think of this?

[pdeva]

+1 to @ivogabe

[mhegazy]

closing in favor of #6615