'foo/bar' style imports not working with @types type definitions

[Naycon]

Not sure if I've misunderstood something regarding module imports in TypeScript 2.0, but the following behaviour is a bit strange to me. Bug? Certainly is inconvenient at least.

TypeScript Version: 2.0.3

_node_modules/@types/foo/index.d.ts_

declare module "foo" {
    export import Card = __Foo.Card.Card;
}

declare namespace __Foo {
    namespace Card {
        export class Card {
            foo: () => string;
        }
        export class CardActions {
            bar: string;
        }
    }
}

declare module "foo/Card" {
    export import Card = __Foo.Card;
    export import CardActions = __Foo.Card.CardActions;
    export default Card;
}

_test-not-working.ts (Cannot find module 'foo/Card')_

import {CardActions} from 'foo/Card';

const action = new CardActions();

_test-okay.ts (No errors)_

import * as Foo from 'foo';
import {CardActions} from 'foo/Card';

const action = new CardActions();

Expected behavior:
First example with imports from 'foo/Card' directly should work.

Actual behavior:
TypeScript cannot resolve 'foo/Card' unless something is directly imported from 'foo' also well.

Workaround:
By importing something (doesn't matter what) directly from 'foo', the other imports work as well.

Original source of problem:
We use material-ui, which lets you import just the parts you need. This worked fine in TypeScript 1.8 using 'typings', but now it seems we need to rewrite our imports when we use type definitions installed via npm (npm install --save @types/material-ui), or use the work around above.

[aluanhaddad]

This works fine for me with both 2.0.3 and 2.1.0-dev.20160927.
Two things of note are that this will not work in ~1.8.0 and that the module names are case sensitive. It works as long as you same casing for the import as in the ambient declaration.

Just a personal opinion, using all lowercase module names is preferable as it is a common convention and maps to case insensitive file systems.

[mhegazy]

Just as @aluanhaddad this is working for me. Please share more context to be able to help further.

[Naycon]

Thank you, you are both correct. Turns out the above works fine if you compile with tsc directly, which is of course what this issue tracker is about.

I saw the problem both in vscode (using typescript 2.0 as tsdk) and when building my app using the webpack typescript loader ts-loader with typescript 2.0. In both those cases, the imports are not picked up, generating both errors shown in vscode and when compiling the app with webpack.

For anyone happening on this thread in search of a solution, the issue can be fixed by adding the modules that are not picked up to types under the compilerOptions in your tsconfig.json:

    "compilerOptions": {
        ...
        // Needed to resolve react imports due to bug in typescript 2.0.x, see https://github.com/Microsoft/TypeScript/issues/11103
        "moduleResolution": "node",
        "types": [
            "material-ui",
            "mocha"
        ]
    }

In this example, material-ui imports could not be resolved due to the import pattern (import { Table } from 'material-ui/table') and mocha injects global variables into tests, which were not picked up either. So this is a workaround if you have similar cases. Not sure if these problems are related to the fact that we use the moduleResolution option above to work around issue 11103. More on this issue for ts-loader and its solution can be found in this ts-loader-issue.

Thanks @aluanhaddad and @mhegazy for looking into this. I'm closing the issue.