-
-
Notifications
You must be signed in to change notification settings - Fork 75
Escope null body failure #78
Comments
Thanks, @friedbizkvit. I can confirm that this is a bug (see below for details). One thing I would note is that it doesn't really make sense to lint 3rd Party definition files that you don't have control over, and you will likely want to exclude them. The issueIt is possible for functions in TypeScript to have no body, because they are simply being used to declare a type. E.g. declare function foo(bar: string): string; ...or directly from the referenced d3 definition file above: declare namespace d3 {
//...other stuff
/**
* Find the first element that matches the given selector string.
*/
export function select(selector: string): Selection<any>;
//...other stuff
} In these cases @nzakas as a quick hack to confirm and work around the issue, I did the following to try and mirror the auto-conversion convention. case SyntaxKind.FunctionDeclaration:
assign(result, {
type: (node.body) ? "FunctionDeclaration" : "TSFunctionDeclaration",
// ...etc Flow seems to handle the two statements above differently to one another, whereas in TypeScript they are both just Let me know if you have any thoughts/questions. |
@JamesHenry it looks like Flow uses |
Ok, these definitely have different implementation details, so I am going to submit them as two separate PRs. First up, the change to |
So finishing this one off... Let's use this as our example: declare namespace d3 {
export function select(selector: string): Selection<any>;
} This currently causes issue because, as mentioned above, the function does not have a body. (Note, there is no declare keyword for the select function, so it is not covered by the first PR that went in for this issue) Basically the Therefore, the way I propose to update the parser is to check on each For clarity and consistency, I would also add to the In other words, the types marked here in red would be prefixed with I feel pretty sure that most of the linting for within TypeScript namespaces will need to come from the plugin, we just need to make sure no core rules are adversely affected, and I believe this prefixing would achieve that. |
I think that makes sense, as I don't think core rules would have any idea how to deal with this. |
What version of TypeScript are you using?
1.8.10
What version of
typescript-eslint-parser
are you using?0.2.0
What code were you trying to parse?
d3.d.ts from
https://raw.githubusercontent.com/DefinitelyTyped/DefinitelyTyped/master/d3/d3.d.ts
What did you expect to happen?
Correct behavior
What happened?
The text was updated successfully, but these errors were encountered: