TypeScript error when multiple type-definitions are available

Hy there,

assume we have a simple react-component as given below:

TestComponent.ts

/// <reference path="./react.d.ts" />

import React = require("react");

interface
State {
    email: string;
    
pw: string;
}

export class Home extends React.Component<any, State> {

    constructor() {
        super();

        this
.state = {
            email: "",
            
pw: "",
        
};
    
}

    render(): React.DOMElement<any>  {
        return React.createElement("div");
    
}
}


In the same folder is also the type-definitions for react (type definitions for React v0.13.1):
https://github.com/borisyankov/DefinitelyTyped/blob/master/react/react.d.ts


So far so good, everything is alright. But if I add now the npm package "typescript-loader" as a dev dependency, I will get a "class name expected here" error:
ClassNameExpected.jpg

package.json:

  "name": "ts-problem",
  "version": "0.0.1",
  "dependencies":
{
    "react": "0.13.x"
  
},
  "devDependencies":
{
    "typescript-loader": "1.1.3"
  
}
}


What is going wrong here? I assume Webstorm is now using the type-definition given in the dependency module, although when I follow the "Component" it leads to the react.d.ts directly in the folder.

Is there a way to fix this?

Thank you,
André

WebStorm 10.0.2



Attachment(s):
typescript-problem.zip
6 comments
Comment actions Permalink

The problem is caused by node_modules/typescript-loader/example/typings/react/react.d.ts: it contains outdated React classes/interfaces definitions, and Component is an interface there - thus WebStorm shows error on a class extending interface. To fix the problem, I can suggest marking this d.ts file as plain text: right-click, Mark As Plain Text

0
Comment actions Permalink
The problem is caused by node_modules/typescript-loader/example/typings/react/react.d.ts: it contains outdated React classes/interfaces definitions, and Component is an interface there - thus WebStorm shows error on a class extending interface


But that seems not be correct behavior. The TypeScript compiler does it correctly (we use TypeScript 1.5 through webpack) by just using the given referenced d.ts file (so this compiles successfully). Is there no way to tell WebStorm to just use what was actually referenced?

0
Comment actions Permalink

No. Unlike the compiler, WebStorm doesn't use ///<reference path> comments - it indexes all .ts files available in the project. This has been done at users' requests

0
Comment actions Permalink
No. Unlike the compiler, WebStorm doesn't use ///<reference path> comments - it indexes all .ts files available in the project. This has been done at users' requests


Well, I think the users are wrong ;)

Our project is not yet very big, but we already have several such collisions. There are many node_modules which come with their own type definitions (sometimes just used in tests). Also, like this, it is possible that WebStorm does not mark an issue, but the ts-compiler will fail (as WebStorm maybe found somewhere a d.ts, but it is not correctly referenced). In my opinion, WebStorm must behave exactly like the compiler, otherwise, there will always be a mismatch between the ts-compiler and WebStorm.

Is it possible to create a flag to enable/disable reference-following?

Regards,
André

0
Comment actions Permalink

@Elana
I am confused by your answer when compared to your answer here made the same day!
https://devnet.jetbrains.com/message/5543477

You need adding the corresponding ///<reference path> comments to your .ts files.



Which is it?

Rick

0
Comment actions Permalink

///<reference path> comments are necessary for TypeScript compiler in order to find the definitions. But WebStorm TypeScript parser doesn't use it - all types defined in typescript files throughout the project are available to it. So, if you need to compile your files with typescript compiler, you have to add comments.

0

Please sign in to leave a comment.