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.
Related
I know this sounds like a strange thing to ask, but is there anyway to get the current line number in a TypeScript script so that it will be emitted to the resulting JavaScript code? I guess I'm looking for something like C's preprocessor
__LINE__
variable.
Edit: I'm asking about the current line in the TypeScript source file (which will usually be different from the corresponding line number in the resulting JavaScript file).
I think souremaps will do what you need. Sourcemaps are a way to map a javascript file back to it's unmodified state.
If you configure your typescript compiler to include sourcemaps then Chrome and other dev tools can reference your typescript files. The result would look like this:
//index.ts
console.log('hey, here is a log!');
console.error('hey, here is an error');
Which would produce this in the console of Chrome's dev tools:
hey, here is a log! index.ts:3
hey, here is an error index.ts:5
The line numbers would be correct even though the typescript complier would strip out the empty lines and reformat the code.
Hope that helps!
I use Closure Compiler on my sources and recently decided to enable the most strict mode via --jscomp_warning=reportUnknownTypes. Alas, it triggered a lot of warnings inside the goog.base itself! I've fixed all the problems in my own code and now I'm looking for a way to silence/remove errors in the closure library code.
I tried to fix errors in base.js but quickly realized it's unfeasible. There are approximately 108 errors in the file and in most cases they are real errors because of goog.base doesn't care much about types: it's a common practice there to define a type like {?} or {*}.
I also tried to use --warnings_whitelist_file to silence warnings I don't care about but it didn't work either. For an error:
..\js\google\base.js:204: WARNING - could not determine the type of this expression
cur[part] = opt_object;
^
I tried different forms in the whitelist file but none has worked:
..\\js\\google\\base.js:204 could not determine the type of this expression
..\\js\\google\\base.js:204 WARNING - could not determine the type of this expression
..\js\google\base.js:204 could not determine the type of this expression
..\js\google\base.js:204 WARNING - could not determine the type of this expression
../js/google/base.js:204 could not determine the type of this expression
../js/google/base.js:204 WARNING - could not determine the type of this expression
..\js\google\base.js:204 WARNING - could not determine the type of this expression
cur[part] = opt_object;
Does anybody have a working solution to have this mode enabled and not get spammed by the errors from the closure library itself?
I use latest Closure Compiler which is:
Version: v20150315
Built on: 2015/03/17 14:18
So, I decided to go the path with silencing warnings in the base.js. For that I've investigated compiler sources (thanks to the authors it's open source) and I found out that flag description doesn't match its actual effect. The description says:
A file containing warnings to suppress. Each line should be of the form <file-name>:<line-number>? <warning-description>
But in fact this guard intercepts matching errors and converts them into warnings. Moreover, line numbers are completely ignored. I see no use of this flag with such behavior but I bet authors had a good reason to implement it this way.
Anyways, I forked from the main branch and fixed flag's behavior. Now matched errors and warnings are actually suppressed (silenced). Line numbers are now considered in the matching.
Syntax of the whitelist file is very similar to the error/warning output. For example if you get error (or warning) like this:
..\js\google\base.js:120: ERROR - could not determine the type of this expression
if (goog.getObjectByName(namespace)) {
^
Then the relevant record in the whitelist file will be:
..\js\google\base.js:120 could not determine the type of this expression
You may add content of multiline errors as comments preceding them with # but only first line will be used for matching.
If this is what you need you may obtain the binary via one of the two ways:
Get the patched sources and build the binary yourself: ihsoft/closure-compiler - Wiki
Get the pre-built compiler binary: ihsoft/closure-compiler - Release v1.0-tuned
tl;dr When there is an error with a test written in intern I don't seem to get error messages that describe on which line the error occurred. I've found a workaround but its not really the ideal solution as it involves messing with code in dependent projects. Does any one have a better way / am I just doing it wrong? Thanks!
Details :
I've seen several times that when there is an issue with parsing a test written in intern (for example failing to close brackets, quotes etc.) that the actual line where the error occurred is not reported, and there is only an error like this (I've subbed in for the actual path as its a work project, but you get the gist):
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
I poked around a little and discovered that there's an undocumented(? - its not in here) parameter for vm.runInThisContext, which if enabled actually provides details of the original error (here and here) - there's some discussion about how this will play out but if I switch dojo.js and hook.js in istanbul (if its running) to use this parameter, I get error messages like this :
<myproject>/test/publisherConfigSpec.js:16
errorCb cat = dfd.rejectOnError(function(error) {
^^^
SyntaxError: Unexpected identifier
at Function.vm.runInThisContext (<myproject>/node_modules/intern/node_modules/istanbul/lib/hook.js:163:16)
at <myproject>/node_modules/intern/node_modules/dojo/dojo.js:745:8
at fs.js:266:14
at Object.oncomplete (fs.js:107:15)
which is the output I want (or at least massively improves my chances of finding and fixing the error) but its not ideal to be messing about with the node dependencies, and it seems to me that it may be too much in flux for a pull request (see most recent update to the API) Is there an alternative way of getting useful output when there's an error parsing the test code input?
Thanks for any advice :)
The output that Node.js provides for SyntaxError is obviously not great, but we probably wonât use undocumented features (theyâre undocumented for a reason!) in any official release of Intern to make it work differently. Non-syntax errors (runtime errors) will be caught and reported competently by Intern to whatever reporters you are using.
In this case, Iâd advise you to use an editor that includes support for syntax checking: Komodo Edit/IDE, WebStorm, SublimeText, Eclipse, vim⌠if you get to the point where you are trying to run syntactically invalid code, your code editor is failing you by not telling you soon enough that youâve made a mistake.
I am using console.log invocations pretty extensively during development of javascript code. I wouldn't like to include these debug logs in the production code and wouldn't like to remove them permanently.
The somewhat obvious solution would be to process/filter javascript sources at the time of deployment on production server. The minimal approach would be to use grep -v console.log sample.js but it will break the code in case of multi-line or complex statements.
The javascript code is actually a template (jinja2) of javascript code but I care to keep it syntactically correct (I put templater tags in comments, strings, etc.).
Is there a smart method of doing it or I have to assume that console.log statements must be single line and the line mustn't contain other, non-debug code?
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.