Which tool can warn me of JavaScript semicolon insertion? - javascript

We use the Closure Compiler to spot syntax errors in JavaScript and window.onerror to spot all other runtime errors. Every file is augmented with "use strict". None of this catches semicolons that were "helpfully" inserted.
I have tried JSLint, but it has pretty specific ideas about how one should code in JavaScript, and so was less useful than I hoped. For example, with JsLint I can no longer use for (var i = ...) style; JsLint gives up as soon as it encounters one of these.
Is there some other static analysis tool for JavaScript that could warn me about semicolon insertion in particular?

There is also JSHint:
http://www.jshint.com/
You can customize what you want it to warn over. It can be run as a standalone checker as part of your build process, or integrated into various editors.

Related

Disabling all jslint rules with Inline Comments

/* eslint-disable */ is the inline comment that disables/ignores all the eslint rules in a js file. Similarly is there any way to disable all jslint rules with inline comment within a js file?
TL;DR -- No.
You used to be able to have JSLint ignore sections of code, but that was removed no later than April of 2013.
Here are some options:
Roll your own ignore
In another answer, I've shown how to hack JSLint yourself if you really really to recreate this functionality. You'd probably have to change some line numbers, but you get the idea.
Id any code smell
The real question, however, is what specifically is it that you want JSLint to ignore? Often there's a code smell associated with wanting to skip something that you might, on further consideration, prefer to fix another way. Or if there's a specific JSLint option that matches what you want to skip, you could turn that option on.
"Quarantine" your code
As an alternative to turning JSLint off for a few lines if you know you want to keep the code, I often put utility functions that, for whatever reason, aren't JSLint happy, in a separate file so that I can have clean files elsewhere in my codebase.

JavaScript - Find All Global Variables Created in Files [duplicate]

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.

qx.log.appender Syntax

When declaring qx.log.appender.Native or qx.log.appender.Console, my IDE (PyCharm) complains about the syntax:
// Enable logging in debug variant
if (qx.core.Environment.get("qx.debug"))
{
qx.log.appender.Native;
qx.log.appender.Console;
}
(as documented here)
The warning I get is
Expression statement is not assignment or call
Is this preprocessor magic or a feature of JavaScript syntax I'm not aware yet?
Clarification as my question is ambiguous:
I know that this is perfectly fine JavaScript syntax. From the comments I conclude that here's no magic JS behavior that causes the log appenders to be attached, but rather some preprocessor feature?!
But how does this work? Is it an hardcoded handling or is this syntax available for all classes which follow a specific convention?
The hints how to turn off linter warnings are useful, but I rather wanted to know how this "magic" works
Although what's there by default is legal code, I find it to be somewhat ugly since it's a "useless statement" (result is ignored), aside from the fact that my editor complains about it too. In my code I always change it to something like this:
var appender;
appender = qx.log.appender.Native;
appender = qx.log.appender.Console;
Derrell
The generator reads your code to determine what classes are required by your application, so that it can produce an optimised application with only the minimum classes.
Those two lines are valid Javascript syntax, and exist in order to create a reference to the two classes so that the generator knows to include them - without them, you wouldn't have any logging in your application.
Another way to create the references is to use the #use compiler hint in a class comment, eg:
/**
* #use(qx.log.appender.Native)
* #use(qx.log.appender.Console)
*/
qx.Class.define("mypackage.Application", {
extend: qx.application.Standalone,
members: {
main: function() {
this.base(arguments);
this.debug("Hello world");
}
}
});
This works just as well and there is no unusual syntax - however, in this version your app will always refer to the those log appenders, whereas in the skeleton you are using the references to qx.log.appender.Native/Console were surrounded by if (qx.core.Environment.get("qx.debug")) {...} which means that in the non-debug, ./generate.py build version of your app the log appenders would normally be excluded.
Whether you think this is a good thing or not is up to you - personally, these days I ship all applications with the log appenders enabled and working so that if someone has a problem I can look at the logs (you can write your own appender that sends the logs to the server, or just remote control the user's computer)
EDIT: One other detail is that when a class is created, it can have a defer function that does extra initialisation - in this case, the generator detects qx.log.appender.Console is needed so it makes sure the class is loaded; the class' defer method then adds itself as an appender to the Qooxdoo logging system
This is a valid JS syntax, so most likely it's linter's/preprocessor's warning (looks like something similar to ESLint's no-unused-expressions).
Edit:
For the other part of the question - this syntax most likely uses getters or (rather unlikely as it is a new feature) Proxies. MDN provides simple examples of how this works under the hood.
Btw: there is no such thing as "native" JS preprocessor. There are compilers like Babel or TypeScript's compiler, but they are separate projects, not related to the vanilla JavaScript.

When creating a linter, what is the expected output format?

Linting is an invaluable technique when crafting code. Yet I find myself wanting to understand the process of linting more. To do this, I am building a basic static code analysis tool with node.
What the linter should do is perform a regex check and if the regex matches, throw an error (or warning depending on the user's config).
I understand that linters traditionally parse code and some even execute checks on an AST, but I want to avoid this entirely. I also understand that my method is bypassing nearly every important part of linting by avoiding the parsed syntax altogether.
The goal is to be able to write a few dead-simple checks and have this as an accessory linter for rapid prototyping. (example: put ^$\n^$ into my linter config and an error would be thrown for two continuous blank lines)
The part of the process that seems undocumented is what type of output is expected to the command line. Here is example output from xo:
/Users/dawsonbotsford/code/regexLinter/cli.js
42:9 error Expected indentation of 6 space characters but found 8 indent
43:9 error Expected indentation of 6 space characters but found 8 indent
43:32 error Missing semicolon semi
And eslint example output:
/Users/dawsonbotsford/code/regexLinter/cli.js
3:1 error Parsing error: The keyword 'const' is reserved
How would I mimic this output with the correct types of shell errors/warnings such that it would be pluggable into sublime-contrib plugins, CI servers, etc.?
If you want it to be pluggable the simplest you can do is write a plugin for ESLint if you need to capture formatting issues. If you want to transform code use šŸŠPutout, the tool Iā€™m working on, it also has a plugin for ESLint so the messages you are going to show, will be accessible in terminal, IDE, CI etc.

JSLint "Stopping" in Visual Studio

I installed JSLint into VS2010. It works great, except that after it gets to line 50 of the file it is checking, it halts with the message JS Lint: Stopping. (37% Scanned).
When I put the same JS into JSFiddle, and use the JSLint tool there...I get a report that spans the entire file. How can I make the JSLint in Visual Studio scan the entire file?
Does it report a validation error on line 50? Perhaps if you could list the content of line 50, somebody may know what feature it does not like.
JSLint unfortunately stops scanning when it comes across a loop with a variable that wasn't defined outside the loop, e.g.
for (var i=0; i < x; i++)
JSLint gets mighty upset if you declare a variable like shown - I think it is to do with the potentially you have not realising that the variable does not have loop scope.
I had a quick play with JSFiddle's JSLint and I could not get it to report anything as an error, so either this doesn't work or it uses an old JSLint, which doesn't include the feature that causes it to stop in Visual Studio. Does it fail when using http://www.jslint.com/?

Categories

Resources