Only Lint in TypeScript Projects?

[wldcordeiro]

This question is related to the new Atom IDE Typescript server. But I've noticed that this is the tool behind it and that there isn't much they can do to enable this type of thing. But is there a way to get the server to only do the TS linting in TS Projects? I have both the TS IDE server and Flow-type as I work on projects using both and it becomes unbearable to see all the red but I really like what this server does for plain JS. If it is something that is already possible could I be pointed to how? I'll PR the Atom plugin with the fix. 😄

[felixfbecker]

Hmm, this server will work with whatever is configured to be included in the tsconfig and sent through didOpen/didChange etc. Not sure how TS is supposed to know what files you want it to run on and which not other than that?

[wldcordeiro]

@felixfbecker if there is no tsconfig at all should the server still do type hinting in a .js file? Because that's what I'm seeing and it makes using this server problematic when you work in codebases that are TS and Flow. To me it seems like the server has features that are for JS and features for TS but the TS features are always on regardless of whether you're in a TS codebase or not (based on the presence of the tsconfig)

[felixfbecker]

Yes, if there is no tsconfig detected a default is used because JS devs usually don't have a tsconfig. This matches what VS Code does. To understand the problem better, let me repeat my question: How would you want TS to know what files you want it to run on and which not other than that?

[wldcordeiro]

@felixfbecker I think we're talking about different things?

The server has TS only features and JS features. I think the TS only features should only run in the presence of a tsconfig the other features should run in any JS file.

Does that clarify?

[felixfbecker]

Not sure what TS only features / JS features you mean? The feature set is the same, it's the same language service running as TS is just a superset of JS. It simply parses the JS as TS. The parser can't handle Flow syntax of course, because that is not valid JS

[liuderchi]

@wldcordeiro I might have similar issues as yours. Quick confirmation here.
Are you saying that

1. you have js codebase (without tsconfig) but with flow-type syntax in some codes
2. you turn on the js-ts-langserver and it does the linting analysis BOTH on
   • js syntax
   • flow-type related syntax, like this:

// foo.js
// @flow

type SetAuthState = (?string) => object
//   ~~~~~~~~~~~~
//  RED LINE LINT ERROR HERE

const setAuthState: SetAuthState = (publicKey) => ({
  payload: { publicKey }
})

4. you don't want the langserver show ts-aspect linting analysis error on type SetAuthState e.g.
   • Severity: Error
   • Provider: ts
   • Description: 'type aliases' can only be used in a .ts file.

[wldcordeiro]

@liuderchi that's precisely it! I'm seeing the TS linting in a JS codebase that has no tsconfig and Flow typed code. That kind of warning should only appear when the codebase has a tsconfig so the tool can be used in concert with others and not degrade user experience.

[tomv564]

The errors you are seeing are not a linting feature (that would be ts-lint).
They are diagnostics reported from Typescript's javascript parser, which is not expecting flow annotations.

This exact problem has come up for VS Code here and here.
Perhaps you can find a good proposal for this server to implement in those discussions (eg. how is javascript.validate.enable: "false" implemented in VS Code)?

[felixfbecker]

It might be reasonable for the TS parser to ignore JS files that have the @flow declaration. But I don't think this is an issue in the language server.

Have you tried creating a tsconfig.json with exclude/include set so that the files are excluded?

[liuderchi]

@tomv564 thanks for clarifying that it's not linting related. I've edited my comment.

@wldcordeiro maybe it's better to edit the issue title to avoid confusion

if you are using vscode there is solution of setting project config in your project
but it's about disabling the parser rather than ignoring flow annotation.

looks like currently only babel with flow plugin can parse js code with flow type, but too bad we're not using it.

@felixfbecker I tried adding following tsconfig.json but it still parsed foo.js as mentioned above.

{
  "exclude": [
    "foo.js"
  ]
}

[damieng]

I think the real problem here is flow typed files are not valid plain JavaScript despite the file extension.

For this to ever work properly the TypeScript Server team would need to bake knowledge of flow into their server so they can 'ignore' the annotations.

Given they are competing technologies I personally think that is unlikely.

[ghost]

News about this?

[skylize]

Given the simplicity of checking for // @flow or /* @flow */ at the top of a file, it seems like a pretty reasonable request to ignore files with this annotation, or at least expose some way for clients to discover if this annotation exists. Do we still need to go further upstream to find a package that actually reads the text?

[damieng]

@skylize The package that reads the text is the Microsoft TypeScript server itself - two packages upstream.

[adammenges]

Throwing my opinion in the ring here and saying that it's been super frustrating to working with a set of projects, some javascript/typescript and some flow. I'm with @skylize here that a simple check for @flow would go a long way to helping developers out.