We Keep Coding

In VS Code Can I Validate my Javascript But Ignore a Specific Typescript Error?

I am writing Javascript in Visual Studio Code (not Typescript). However, I added "checkJs": true ("Enable type checking on JavaScript files") to my compilerOptions in jsconfig.json to enable automatic imports.
Now that I have done that, I'm getting Typescript errors (squiggly lines), for instance:
JSX element type 'Foo' does not have any construct or call signatures. ts(2604)
I could remove these by disabling validity checking, but then I'd lose normal Javascript validity checking.
My question is: is it possible to have automatic imports, and Javascript validity checking, but not have Typescript errors in VS Code? For instance, is there some flag I can set in jsconfig.json to disable errors with "ts" at the end?
And if not, how do I fix Typescript errors in a Javascript file ... without having to adopt Typescript?
EDIT: Just to help clarify the kind of solution I'm imagining ... let's say we were talking about ESLint here. Yes I could add a comment at the top of a file to make ESLint ignore that file, but then I lose all linting whatsoever.
I'm more looking for the equivalent of being able to say "ts2604": false or "ts*": false in an .eslintrc file, or something more like that. In other words, I don't want to adopt Typescript, or lose all type awareness either ... I just want VS Code's great Javascript features, without large chunks of my code being underlined by error/warning messages that I can't do anything about.

This could be a red herring, but are all your errors JSX related? TypeScript can handle JSX (in *.tsx ot *.jsx files) if you specify the factory to use for the JSX. The error looks like TS can't find the factory class (so it's got <Foo> and doesn't know what to pass it to). Typically this will be something like (the settings say React, but they're the same for Preact or other JSX libraries):
"compilerOptions": {
"jsx": "react",
"jsxFactory": "probably the same as transform-react-jsx setting in your plugins"
}
There's much more on that in the TS docs.
Generally I find it best practice to fix TS errors before JS anyway, but that isn't always practical, so another option is adding // #ts-ignore on the preceding line or // #ts-nocheck to skip type checking in the file.
// #ts-ignore is really intended for this kind of situation, but it's not a long term fix - you're upgrading, you know it works, you just need TS to skip the failing check for now. But, when you know the code works and TS is missing a definition somewhere it can be the right patch.

VS Code's JavaScript type checking is powered by TypeScript. The errors you are seeing in your JS files are not TypeScript language errors, they are the TypeScript engine saying: "Hey this JavaScript code looks like it is invalid". The TypeScript engine tries to understand JavaScript as well as possible, but JavaScript's dynamic nature can sometimes trip it up and you may need to help it along with some JSDoc annotations .
So ideally you should address these errors. If this is not possible, you can suppress the errors using a // #ts-ignore comment on the line above the error (this is offered as a quick fix for the error)
This TypeScript feature request also tracks the ability to suppress specific error codes.

Lately I have been coding in React with Visual Studio Code and we have a team recommandation for using ESLint extension.
It has many configuration capabilities, and the following one may match with your needs :
eslint.probe = an array for language identifiers for which the ESLint extension should be activated and should try to validate the file. If validation fails for probed languages the extension says silent. Defaults to ["javascript", "javascriptreact", "typescript", "typescriptreact", "html", "vue"].

Where is this VSCODE intellisense coming from?

In VSCODE I see the following intellisense:
When exploring node_modules/sanctuary/index.js, I find a function toMaybe, but it doesn't appear the definition is coming from here because they do not match
//# toMaybe :: a? -> Maybe a
//.
//. Takes a value and returns Nothing if the value is `null` or `undefined`;
//. Just the value otherwise.
//.
//. ```javascript
//. > S.toMaybe (null)
//. Nothing
//.
//. > S.toMaybe (42)
//. Just (42)
//. ```
This is in contrast to other functions that commonly display like this:
Two questions:
Where should I look next?
How can I document my own functions like this?
UPDATE:
Lukas Bach and ippi have pointed out, one part, Sanctuary.Static.toMaybe<A>(p: A): Maybe<A> comes from the Automatic type acquisition feature.
Even after deleting all #types from ~/Library/Caches/typescript/2.9/node_modules/types-registry, I still see some docs.
I also was not able to find the text toMaybe :: a -> Maybe a in the #types/sanctuary/index.d.ts file or anywhere in the #types directory.

The programming language TypeScript, a superset of JavaScript, allows definitions for proper types on functions and variables. TypeScript can be compiled down to JavaScript, which removes all type annotations, and a seperate type definition file (*.d.ts) can be exported during transpiliation. TypeScript type definitions are nowadays commonly provided for JS modules either directly in the module repository itself or as part of the DefinitelyTyped repository.
To get such type annotations for your own code, you can either write your code in TypeScript in the first place or write additional custom type definition files by yourself.
This is not the only way to write type definitions, but at the moment the most prominent one.
Edit: Ok, I did not really look into the package that you've mentioned earlier. But I've tried it out, and this is the IntelliSense annotation, which it gives to me.
And this seems to be coming from the TS typing:
toMaybe<A>(p: A | null | undefined): Maybe<A>;
These typings are located at https://www.npmjs.com/package/#types/sanctuary.

VSCode always shows type definition and not the actually implementation

do any of you face this problem , where vscode always take you to the type definition of a function and not the implementation.
For example,
I right click on the react setState function as below,
And VS code shows me the typescript file.
If its problem a, how do i fix it.
If not then how do I look at the implementation and not the type definition of a function.

This is a limitation of VS Code's intellisense. We don't attempt to parse js from inside node_modules for IntelliSense, so we have no way of mapping back to the original source code. Instead we rely on *.d.ts to provide definitions.
These two issues are tracking possible improvements to this:
https://github.com/Microsoft/TypeScript/issues/6209
https://github.com/Microsoft/TypeScript/issues/16792

In vscode v1.67 there is update with new Go to Source Definition command
Jump directly to a JavaScript implementation of a library function
using the new Go to Source Definition command. You can learn more
about this feature and share feedback in TypeScript issue #49003.

Closure optimization + keeping function name

I have simple example:
Javascript:
function testBut(b){
alert("!");
}
HTML:
<button onclick="testBut(this)">Test</button>
Now I run my .js script through Google Closure compiler (running from commandline), and I want to keep testBut function intact.
I read in many places that I have to use --externs option and define another file with names of exported functions, in this case it would hold just:
function testBut(b){}
And additionally I need to add funny line to my js code:
window['testBut']=testBut;
So now questions:
is that really so stupid system in Closure with two bug-prone steps to be done, in order to keep desired function?
is there no "#..." annotation that would simply suit same purpose? I tried #export, but it requires --generate_exports option, and still it generates similar ugly and useless goog.a("testBut", testBut); in target code (I tried same code, and those goog.a(...) seems simply useless), and this still requires the exports file
Ideally I'm looking for simple annotation or commandline switch that would tell "don't remove/rename this function", as simple as possible, no code added, no another file.
Thanks

Don't confuse externs and exports.
Externs - provide type information and symbol names when using other code that will NOT be compiled along with your source.
Exports - Make your symbols, properties or functions available to OTHER code that will not be compiled.
So in your simple example, you need:
function testBut(b){
alert("!");
}
window["testBut"] = testBut;
However this can be simplified even further IF testBut is only for external calls:
window["testBut"] = function(b) {
alert("!");
};
Why not always use the second notation? Because internal usage (calls within the compiled code) would then have to use the full quoted syntax which blocks type checking and reduces compression.
Why not use a JSDoc Annotation for Exports?
This question comes up a lot.
For one, there isn't global consensus on how exports should be done. There are different ways to accomplish an export.
Also, exporting symbols and functions by definition blocks dead-code elimination. Take the case of a library author. The author wishes to compile his library exporting all public symbols. However, doing so means that when other users include his library in a compilation, no dead-code elimination occurs. This negates one of the primary advantages of ADVANCED_OPTIMIZATIONS.
Library authors are encouraged to provide their exports at the bottom of the file or in a separate file so that they can be excluded by other users.
It has been suggested before to provide a command line argument to control exporting based on a namespace. IE something like --export mynamespace.*. However, no author has yet tackled that issue and it is not a trivial change.

How can I use closure type annotation with Aptana?

If I enter the follow JavaScript code in Aptana Studio 3 then I expect some errors but it show nothing.
/**
* #type {string}
*/
var abc = 23;
abc.doesNotExists();
How can I enable the support for closure type annotation?

Currently Aptana supports only the annotations but not also the actual type checking. In order to type check you have to compile that code using the google closure compiler. If you set the compiler to the full optimized mode it will yell the warning that abc is a string ( as you placed it in the annotation comment ), but you have set a number value instead. In order to be able to take this from the command line of the closure compiler and integrate it into aptana you would need a plugin, but as far as i know, the closure plugin for eclipse/aptana has not been updated for the last 1 or 2 years, and also this feature that you would like to have was not implemented in the latest release of that plugin.
In other words, either you run the closure compiler separately and check the for warnings or errors in certain files, OR you fork the repo of the eclipse closure plugin and implement this feature yourself.
I had the same issue as you, but having too much work to do pushed me into opting for the first solution ( running the closure compiler separately in a console ). I had even placed a hook so each time i would save a file in that project it would run the compiler in the console view of aptana so i could check if i had introduced new errors or warnings.