Is there a VSCode extension that shows data type of a variable (like if we hover above that variable)? Presumably by detecting the type of a variable by looking at its initialization, and maybe even follow subsequent re-assignments? I know that using Typescript will give me great tooling which will do what I am seeking, but I don't want to use Typescript.
No not really, that's the nature of dynamic programming. VS Code itself can sort of guess, but it's mostly based on frequent strings used within the file or directory.
The closest is JSDoc (which has more uses than just types, you should probably already be using this) and indirectly using Typescript in your plain .js files to help VS Code.
At the top of your files add this:
// #ts-check
https://code.visualstudio.com/docs/nodejs/working-with-javascript#_type-checking-javascript
Related
While trying to get started with Reason, in one JavaScript project, I've got an extremely light file that tries to be a Reason-typed interface to the existing, heavy, library:
/* TheLibrary.re */
type engine
external addEngine : string -> engine -> unit = "" [##bs.val] [##bs.module "../"]
However, when I try to use that library in a ReasonReact project (having added #org/the-library to the bsconfig.json bs-dependencies),
/* AComponent.re */
[#bs.val] [#bs.module "#org/game-engine/dist/game-engine.js"]
external gameEngine : TheLibrary.engine = "default";
/* Further down, a React lifecycle method, */
TheLibrary.addEngine("Game", gameEngine);
I get errors about ../ being not found, relative to that React component:
./src/components/main-menu/AComponent.re
Module not found: Can't resolve '../' in '/Users/ec/Work/reason-reacty/src/components/main-menu'
I've also tried, instead of ../ in TheLibrary.re's external declaration:
#bs.module "./index.js" (the direct, ES6 entry-point for the untyped-JavaScript side of the package in question,)
#bs.module "#org/the-library", the entire name of said library (even though I'm typing inside that library???)
Please help! I'd love to be able to further adopt ML, but I'm having the hardest time wrapping my head around ReasonReact's dependency-resolution!
Additional context:
So, we're trying to build our first ReasonReact project, and we've successfully added baby's-first-opaque-types to one of our internal libraries and include that in the ReasonReact page with something like the following — which works, by the way:
/* Imports.re */
type engine;
[#bs.val] [#bs.module "#org/game-engine/dist/game-engine.js"]
external gameEngine : engine = "default";
[#bs.val] [#bs.module "#org/the-library"] [#bs.scope "default"]
external addEngine : (string, engine) => unit = "";
This yields, when we Imports.(addEngine("Game", gameEngine)), the global setup line we need: TheLibrary.addEngine("Game", GameEngine). I'm in the very first stages of trying to upstream that typing-information into the parent project, and publish that code to npm, so that all consuming projects can start to use Reason.
t sounds like you might be a bit confused about the different tools that make up your toolchain, so let's first go through them one by one to put them in their place:
ReasonReact is a library of opinionated, "thick" bindings to react.js, which despite the name isn't actually all that Reason-specific, except for its integration with Reason's JSX syntax. It would be more accurate to call it a BuckleScript library.
Reason is mostly just the syntax you use, but is often also used more broadly to refer to the ecosystem around it, and usually also imply that BuckleScript is being used.
OCaml is the underlying language. The "semantics" of Reason, if you will.
BuckleScript is the OCaml-to-JavaScript compiler. It compiles ONE source file, which is considered a module, into ONE JavaScript module, but also requires the type information of other OCaml modules as input.
Now, I suspect you already know most of that, but what you do not seem to know is that NONE of these actually do ANY dependency resolution. These next parts of your toolchain are what does that:
The BuckleScript Build System, or bsb, is what finds all the modules in your local project according to what you've specified in src and any BuckleScript libraries you've listed in bs-dependecies in bsconfig.json. It will figure out the dependency order of all these and feed them to the compiler in the correct order to produce one JavaScript module for each OCaml module (along with some other artefacts containing type information and such). But it will not resolve any JavaScript dependencies.
Lastly, webpack, or some other JavaScript bundler, is what you likely use to combine all the JavaScript modules into a single file, and which therefore needs to resolve any JavaScript dependencies. And this is likely where the error message comes from.
Using [#bs.module "some-module"] will make the BuckleScript compiler emit var ... = require('some-module') (or import ... from 'some-module' if es6 is used), but BuckleScript itself will not do anything more with it. The string you pass to #bs.module is the same string you would pass to require if it had been an ordinary CommonJS module (or whatever other module format you have configured).
Also note that the import is not emitted where the external is defined, but where it's used. You can work around, or "ground" it in a module by re-exporting it as an ordinary definition, ie. let addEngine = addEngine.
In order to precisely answer your question I would need to know which bundler you use, where you've configured BuckleScript to output its JavaScript artefacts, where the externals are used, not just defined, and where the external JavaScript module is located. But I hope all this underlying knowledge will make it easy for you and future readers to identify and resolve the problem yourself. If you're still a bit unsure, look at the compiled JavaScript artefacts and just treat them as ordinary JavaScript modules. At this point that's really all they are.
I'm trying to extend Monaco Editor to allow users to write in a hybrid of JavaScript and another language, using delimiters to separate them within the same file, similarly to how Markdown allows writing multiple languages using fenced code blocks.
The difference is that I want to keep all the other IDE features that Monaco has built in for JavaScript, such as linting (done via diagnostics), smart auto-completion, jump-to-definition, auto-formatting helpers, and every other IDE feature that comes with Monaco's built-in JavaScript mode. I'd like these features to still work within the JavaScript portion of the code that Monaco is editing, and be disabled for the sub-language portion.
My first attempt was to call setMonarchTokensProvider, passing in a modified version of TypeScript's tokenizer rules. Specifically, I was able to add the beginning-fence delimiter to the root rule and create a new rule for the sub-language in the same way the documentation for Monarch (Monaco's syntax highligher) describes, using #nextEmbedded. (For testing purposes, I've been hard-coding CSS as the embedded language.)
When I call setMonarchTokensProvider like this for the language "javascript", it completely ignores this syntax highlighting tokenizer, and colors the code-fences of CSS as invalid JavaScript, indicating that you cannot override the built-in JavaScript mode this way.
When I call setMonarchTokensProvider with a new language (e.g. "mylang") and set the editor to use that language, it provides correct syntax highlighting (!) for this CSS-in-JS hybrid language. But all other advanced features that were found in the JavaScript mode are no longer present. The editor didn't have any smart auto-completion for methods defined on classes in the same file, or any in-editor error-reporting for invalid syntax, or any of its trademark JavaScript IDE features.
So my next attempt was to modify the pre-bundled Monaco code's TypeScript definition to include my custom syntax highlighting rules. This correctly highlighted my CSS-in-JS code completely (!), when setting the language to "typescript", and left all the other features intact (!) including diagnostics reporting (live-validation and underlining of errors), auto-completion, all of it! (I didn't try it with "javascript" but it's safe to assume it probably works or is trivial to get it working, since JavaScript is actually implemented as a variant configuration of the TypeScript mode in Monaco.)
Unfortunately, it also considered the entire CSS portion of it, including the fence around it, to be invalid JavaScript code.
I know that this is theoretically doable, because within HTML mode, you can embed CSS or JS with full support for proper validation and auto-completion and every other IDE feature; basically, every sub-language in an HTML file works like it's in its own file: HTML features in the root of the file, CSS features within style tags, JS features within script tags.
But digging into the TypeScript plugin's implementation inside Monaco, it's not clear where to begin editing this, either as a user of Monaco the library, or by forking it and patching it up where necessary. I started at trying to modify the DiagnostcsAdapter [sic] and tracing where it's actually implemented, but I got stuck two function-calls deep, where it seems to push a promise of syntax validation that returns a value that's used later, but the implementation of getSyntacticDiagnostics just shells the work out to some other implementation that I can't find anywhere else in the repo, nor in the monaco-languages repo or the vscode repo.
I make the similar thing. My solution is to place non-JS code inside a block comment:
regularJsCode()
/*
[your-syntax-identifying-start-token]
place any syntax you want here
[your-syntax-identifying-end-token]
*/
regularJsCode()
Then you can process it with your tools, parsers, IDE extension etc. And the coolest part you can make VSCode to syntax-highlight it like you want so it won't seem like some hack.
This approach is preferrable because your JS file still remains a 100% valid JS file.
If you still don't want to put your syntax into comments, then you should create your own file extension like .jsx/.tsx. In practical, VSCode terms this means you need to create VSCode extension with language server and stuff. This is not so easy, but the documentation is good. You could assemble your own JS highlighting code inside your VSCode extension using language server: https://github.com/sourcegraph/javascript-typescript-langserver
According to the creator of Monaco:
Architecturally, you can do the following:
use monaco-editor-core directly
define a new language to the editor
fork monaco-typescript and change it to work with your newly defined langauge id. Then, modify the TS language host code to not pass the original models to TypeScript, but first run a preprocess which strips your custom language out of the text, and then only passes on valid TypeScript to the TS compiler. One idea is to replace each character that you remove with a space. This will leave all the position/offset computation work without any effort on your side.
Good luck!
I was trying to make NodeJs work with Kotlin for a HelloWorld example here.
As per the Kotlin JS documentation, #JsName annotation is required for overloaded methods. But in my experience, it is required even for a single method. Without this annotation the compiler adds a suffix to the method name as shown in the screenshot.
Is this a bug? Or am I missing something?
I'm using Kotlin 1.1.0 module provided by NPM (please check the GitHub link above for the complete codebase if required).
Kotlin compiler mangles names all functions, except for those which don't take any parameters. The motivation is: you can add overloaded function later, and this should not break binary compatibility of the code. As for #JsName: it depends on your goal. I don't know it and hence I can't tell whether you shuold put #JsName annotation on each method. If you are developing a library which is intended to be used from JavaScript, yes, you probably need to put #JsName on each function you want to be accessible from JavaScript. We are going to add another annotation which turns off mangling on entire class or file.
I am gathering a lot of Javascript code from untrusted people and have to integrate it in my project. As is is untrusted, I would like to check if it doesn't do something nasty.
My main concern is the variables the code uses.
To check it is OK, I would like to parse all the code and verify the name of the variables. For instance, that all the variables are included in window.sandboxedVariables.
Is it possible to parse a Javascript code (in any language but preferably Javascript or bash) and get the list of all the variables ? Is it possible to do the same with the imported libraries ?
Is it possible to do with Uglify ? I read a bit the API documentation and found nothing specific.
Thank you very much !
Assuming you're talking about global variables, you can do the following:
clone the window object
load/run the untrusted script
compare the window object to the cloned one
move all newfound items into window.sandboxedVariables
However, this won't work if the untrusted script overrides one of the existing properties (variables) of window.
eslint is a JavaScript source code linting tool that lets you write custom plugins. You should be able to write a plugin that meets your needs. Plus, the plugins can be written in JavaScript.
http://eslint.org/docs/developer-guide
It is impossible to write an algorithm that verifies untrusted JavaScript code. You can parse it, you can run it in a sandbox and analyze its actions. But you can never be sure you've identified everything it might do or every variable it might use once you run it in your real environment.
If you don't trust it then either only run it in a secure sandbox or don't use it.
You could use Mozilla Rhino. It is a JavaScript engine written in Java.
Here you can find an example similar to what you are trying to do:
http://ramkulkarni.com/blog/parsing-javascript-code-using-mozilla-rhino/
I'm thinking about using TypeScript to create an online app, and this will require saving of data online.
What are my options in regards to that?
Is there anything specific to using TypeScript which makes that easier or harder?
Ideally I would use a service like Parse.com to save data, can Typescript be connected to Parse or would I have to rely upon plain JS?
TypeScript runs wherever javascript runs. So
Your options are the same as javascript.
Typescript compiles down to javascript. And it is designed to be a superset of javascript so your javascript will be valid typescript as long as you have variables declared and sometimes types mentioned.
Optional static typing + easier syntax is what makes developing in TypeScript easier.
Static typing makes refactoring and intellisense more reliable. Having an easier syntax for classes / modules means you are more likely to structure your code better.
Yes you can use parse.com with typescript
The recommended way to do that is to create a declaration file describing your javascript code. In the beginning it can be as simple as:
declare var parse:any;
I wrote some guidance on the matter here : http://basarat.github.io/TypeScriptDeepDive/#/declarations
There is a huge resource of declaration files you can find at https://github.com/borisyankov/DefinitelyTyped . In particular check out FireBase : https://www.firebase.com/ and its declaration file : https://github.com/borisyankov/DefinitelyTyped/tree/master/firebase However there isn't one on parse.com yet which is why I mentioned the way to write your own.
Additionally you don't need a declaration file if you do not want any impressive static checking of the typescript code that interacts with the parse.com's api.