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.
Related
So I'm trying out IntelliJ and possibly moving away from Eclipse. I see I can hover over Javascript methods and actually see some info, which is great. But how do I find out more about what is being shown to me? In the pic below, what does the "?" mean? Does 'void' mean there is not a 'return' statement?
Is this JSDoc? This is old legacy code, so I know there is not any commenting above the function to give more info, so I'd like to know what's going on here. Is this just IntelliJ extrapolating the function arguments and creating its own interpretation?
I assume there's a guide or legend out there for this. But after searching around for a while I feel like I don't know the right search term to look for. Any help is appreciated.
EDIT: We don't use TypeScript at all in our current app.
Quick documentation is mostly based on comments in code. In this case the information comes from bundled definition files (In this case, a d.ts file which is a TypeScript type defintion file). For the methods defined in the project or in its dependencies, IDEA shows information from the JSDoc comments attached to functions.
Looks as if the function is defined in a d.ts file, because explicit type declarations are used, so ? indicates optional parameter, and void means that the function is not returning a value.
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.
When using intellisense in VS-Code, it gives autocomplete suggestions for an older version of expect than what I'm using,. The API has changed since it was donated to the Jest project, but for some reason, it still shows the old methods, but none of the replacement methods, like toHaveProperty.
Took a lot of effort to find out why my tests weren't working, but haven't been able to find an answer as to what could be the cause.
VS Code sources its type definitions for JavaScript from the #types namespace on NPM, which contains definition files that are automatically pulled from the DefinitelyTyped GitHub repository.
In your case, the type definitions will be coming from the #types/expect package, which specifies in the README that it exposes the files from https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/expect.
If you look at the timestamps on said files, you'll notice they haven't been updated in 5 months! That is most likely the source of your issue.
You (or someone else) will need to submit an updated type definition to make automatic type acquisition function properly for that library. Alternatively, you can override the type definitions locally or disable the feature altogether.
Using the Closure Compiler,I get the warning:
cannot instantiate non-constructor
This is just a warning and the code runs fine. Still, I hate having warnings that I know have no affect on the app. Some of the code where this warning occurs is from third party libraries but some of it is from my own.
Is there a way to just suppress this warning?
You can use this option:
--warnings_whitelist_file VAL : A file containing warnings to
suppress. Each line should be of the
form
<file-name>:<line-number>?
<warning-description> (default: )
This might be useful to suppress warnings from the 3rd party code:
--hide_warnings_for VAL : If specified, files whose path
contains this string will have their
warnings hidden. You may specify
multiple.
There is also this:
--warning_level (-W) [QUIET | DEFAULT : Specifies the warning level to use.
| VERBOSE] Options: QUIET, DEFAULT, VERBOSE
(default: DEFAULT)
To see the complete list of available options execute a command like this:
java -jar ../closure-compiler/target/closure-compiler-1.0-SNAPSHOT.jar --help
Note however that you are passing up some of the benefits of Closure Compiler for doing type-checking on your code. If you provide more details about the error and where in the code it happened I might be able to suggest the annotation to use there.
For you own code, either use ES2015 class syntax, or add #constructor annotations to function constructors. This tells the compiler that the function is intended to be called with the new operator.
For 3rd party code, hiding the warning is the best you can do.
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.