Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Naycon opened this issue Sep 27, 2016 · 3 comments
Closed

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

Naycon opened this issue Sep 27, 2016 · 3 comments
Labels
Needs More Info The issue still hasn't been fully clarified

Comments

@Naycon
Copy link

Naycon commented Sep 27, 2016

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
Copy link
Contributor

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
Copy link
Contributor

mhegazy commented Sep 28, 2016

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

@mhegazy mhegazy added the Needs More Info The issue still hasn't been fully clarified label Sep 28, 2016
@Naycon
Copy link
Author

Naycon commented Sep 28, 2016

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.

@Naycon Naycon closed this as completed Sep 28, 2016
@microsoft microsoft locked and limited conversation to collaborators Jun 19, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs More Info The issue still hasn't been fully clarified
Projects
None yet
Development

No branches or pull requests

3 participants