I know that I can type into Chrome or FF the following command:
Object.keys(window);
but this displays DHTMLX stuff and also function names in which I'm not interested in. And it doesn't display variables in functions that have not been executed yet. We have more than 20,000 lines of JavaScript codebase, so I would prefer static code analyis. I found JavsScript Lint. It is a great tool but I don't know how to use it for displaying global vars.
So I'm searching for memory leaks, forgotten var keywords, and so on...
To do [only] what you're asking, I think you're looking for this:
for each (obj in window) {
if (window.hasOwnProperty(obj)) {
console.log(obj);
}
}
I haven't linted that code, which is unlike me, but you get the idea. Try setting something first (var spam = "spam";) and you'll see it reported on your console, and not the cruft you asked about avoiding.
That said, JLRishe is right; JSLint executes JavaScript in your browser without "phoning home", so feel free to run it. There are also many offline tools for JSLinting your code. I use a plugin for Sublime Text, for instance.
If you'd like some simplest-case html/JavaScript code to "wrap" JSLint, I've got an example here. Just download the latest jslint.js file from Crockford's repository into the same directory, and poof, you're linting with a local copy of JSLint.js. Edit: Added code in a new answer here.
Though understand that you're linting locally with that wrapper or when you visit JSLint.com. Honestly, I can say with some confidence, Crockford would rather not see our code. ;^) You download JSLint.js (actually webjslint, a minified compilation of a few files) from JSLint.com, but you execute in the browser.
(Admittedly, you're technically right -- you never know when that site could be compromised, and to be completely on the up and up, you sh/c/ould vet jslint.js each time you grab a fresh copy. It is safer to run locally, but as of this writing, you appear safe to use JSLint.com. Just eyeball your favorite browser's Net tab while running some test, non-proprietary code, and see if any phoning happens. Or unplug your box's network cable!)
Rick's answer to use "use strict"; is another great suggestion.
A great way to catch undeclared variables is to add 'use strict' to your code.
The errors will appear in the console, or you could display them in a try ... catch block:
'use strict';
try {
var i= 15;
u= 25;
} catch(ee) {
alert(ee.message);
}
I found a very good solution to list all the global variables with the jsl command line tool:
Here is the documentation
I just have to put /*jsl:option explicit*/ into each file that I want to check. Then it is enough to run ./jsl -process <someFile> | grep 'undeclared identifier'
It is also possible to use referenceFile that contains some intentional global variables /*jsl:import <referenceFile>*/ so these variables will not be listed.
Related
I was about to comment out blocks of code that just printed/console.logged debugging info, and I thought, why don't I create a global scope "debug" variable, and instead of commenting this code out, put an if (DEBUG == 1) {} around it?
The reason I ask is because I'm working with javascript at the moment, and my code is spread across a few .js files. If I create a DEBUG variable in app.js, I'll need to export it from app.js and require it in other files; is this consistent with best practices? Is there a better way to do what I'm thinking of?
There are many ways to do this. Most logging libraries will have levels that allow you to only output or see messages whose levels are above some minimum. Alternatively, if you're just using console.log or console.debug and content to keep those in lieu of more robust log streams, you can change the behavior of these by using your own logging library; for example, if you have a debug.js file that exports your debug() function, import/require it once in each other file and just call debug() instead of console.debug() (or you can actually reassign console.debug = debug but that will have potential side effects in any dependencies or dependent code).
In debug.js, your function can simply check an environment variable (in node.js or similar) or global variable (in the browser) or even a hard-coded flag, and immediately return (doing nothing) if you're in production or not in the mood to print debug messages.
Take a look at bunyan's log levels as an example of how a popular logging library handles this: https://www.npmjs.com/package/bunyan#levels
If you are programming the browser and you want a quick and dirty global variable, you can do window.myVar = 'whatever'.
TL;DR: How can I access variables/functions/names that are defined in ES Modules from the debugger?
More context: I'm a relatively experienced JavaScript programmer, but new to Modules. I've followed the tutorial at MDN here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules. They have a good set of examples here: https://github.com/mdn/js-examples/tree/master/modules
In that collection, say in the "basic-modules" example, (live code here: https://mdn.github.io/js-examples/modules/basic-modules/) there is, for example, a function called random in the file modules/square.js. Suppose I want to execute that function in the debugger, just to try it out, or because it's my code and I want to test/debug it, or I want to demonstrate to another coder what the function does. All the stuff you expect to do in a REPL or debugger. Is there a way to do that? I've tried both the Firefox debugger and the Chrome debugger, with no luck.
Back in the pre-Modules era, that code would be put into the global namespace (making access easy) or it would be locked up in an IIFE (making access impossible) or maybe in some home-made module system (access depends). I am hoping that the new Modules system still allows the debugger access to the names inside modules.
Thanks.
It says in the docs:
Last but not least, let's make this clear — module features are imported into the scope of a single script — they aren't available in the global scope. Therefore, you will only be able to access imported features in the script they are imported into, and you won't be able to access them from the JavaScript console, for example. You'll still get syntax errors shown in the DevTools, but you'll not be able to use some of the debugging techniques you might have expected to use.
To take your example from before, you'll need to invoke that function from a scope where it is visible, i.e where it's been imported:
import { random } from 'path/to/square.js'
debugger; // you should be able to invoke random() from here
I'm an desktop application developer trying to learn the avalanche of technologies for web programming. I decided to focus with Angular(2-4 whatever) because it seemed like the it might be around for more than a year. I'm taking a course that is focusing on TypeScript right now. I'm using Visual Studio Code (1.14.0 - I just updated it) with TypeScript version 2.4.1 (That's what it shows in the lower right corner).
The instructor is showing us how to 'transpile' with command lines (which was another mess I wasted my morning on - see tsc.cmd as opposed to tsc).
The example in question is simply this one line, the first and only line in the Visual Studio Code editor:
let message = 0;
I get the red line of error under the 'message' telling me that:
[ts] Cannot redeclare block-scoped variable 'message'.
It worked for the instructor (on his MAC) but so did the ts compiler command.
If I change it to
let messag = 0;
The error goes away. I can't find where message is a command, statement or global variable in Type Script.
It seems like I'm running the latest of node and type script. I just worry that something is not correctly installed on my machine.
I am still getting use to the idiosyncrasies of VS Code.
My issue was that I put 'archive' copies of my previous code in a subfolder not realizing that these would be loaded as part of the 'assembly'.
Don't simply close the folder! If you are looking at just a single file, the editor will turn off intellisense for typescript.
My solution was to move my archived files out from under the folder AND rename them so their extension was no longer .ts.
Is it a npm project? If not - make it one and use the features of tsconfig.json, where you can exclude files if necessary. Maybe also use GIT? You could create a template repo (with a default configuration) for cloning and then adding specific stuff.
For testing purposes, obviously not for production. What is the best way to do this?
Googling I found this tutorial, and of course the project on github.
For starters which files do I need to run:
// removed
and is there an API reference. I see there is a large comment block in jslint.js that seems to server this purpose but was wondering if there is something easier to read.
Because the client has no file access, I was planning on ajaxing the code in to get its contents.
Please never the mind, on why I want to do this on the client.
If you include the JSLint script you will have access to a single global variable, JSLINT. You can invoke it with a string and an optional map of options:
var valid = JSLINT(code, options);
The result will be true or false, depending on whether the code passed the check based on the provided options.
After this call you can inspect the JSLINT.errors property for an array of warnings, if any.
This is precisely what I have done to build JSLint integration into the editor in the articles on http://jslinterrors.com.
Have you looked at http://jshint.com/ ? Source is available here: https://github.com/jshint/jshint/
The browser bundle is available here: http://jshint.com/get/jshint-2.1.10.js and the docs describe how to call it (http://jshint.com/docs/)
I need to modify WebDriverJS for my purposes. The compiled source is giving me a hard time debugging, though. Describing function names and comments would help me out big time! So I was wondering whether it is possible to compile WebDriverJS without minimizing it's content.
The build.desc for the JavaScript compilation is using js_binary which is using Google Closure Compiler. Anyone of you know how to compile it and preserve functionnames and comments? This would rather be a merge of all sources then a compilation.
Thanks to Chads Post in "Potential differences between compiled and uncompiled Javascript" I've taken a deeper look at the flags of closure compiler.
--compilation_level=WHITESPACE_ONLY preserves function and variable names
--formatting=PRETTY_PRINT doesn't remove linebreaks
--formatting=PRINT_INPUT_DELIMETER gives me a better overview in which file to search for the source
Unfortunately I still couldn't figure out how to save the comments, but thats just a small problem since I can look them up in the source code.
Update:
Seems like the compilation_level doesn't remove the goog.required-calls. I've got to remove them somehow, because the script doesn't work with them.
Update 2:
I've removed all goog.require($mod) and goog.provide($mod) calls and defined Objects where needed (typically to find right after the // Input $int comments). It's working now.