What's the correct way to prevent warnings on IntelliJ, for example this code:
the .children_str gives warning Unresolved variable children_str. The children_str property is a string, and row is an Object.
Normally I would add a namespace (I don't know what is it, but it removes those warnings):
But then another warning appeared Unresolved function or method split()
What's the correct way to tell IntelliJ that children_str is a string to remove those warning message?
You can hit Alt+Enter to see Idea's way to resolve this warning. If there are none, you can always disable JavaScript Inspections. There are two ways:
Alt+Enter then click right arrow and select Disable Inspection
Go to File -> Settings -> Inspections and find JavaScript inspections options. There you can disable any inspections that annoy you, like Unresolved JavaScript function or Unresolved JavaScript variable
The warning can be removed by assigning and adding || operator, for example:
row.children_str = row.children_str || '';
Related
There is a web online, library or something to detect old IE functions that are not compatible with Chrome/Firefox or just ES6?
Like: document.all, event.returnValue, etc
JsHint/Jslint are not detecting them as deprecated or incompatibles
It's not quite fair to say JSLint won't tell you about deprecated properties. Let me explain.
Recall first that JavaScript is a dynamic language. You can assign any property to [almost] any object. You could assign all to window in a browser context if you wanted just by saying window.all = "Muahahaha!!! I'm evil!!!". You could add .all to a string with...
var spam = "a string";
spam.all = "I'm still evil!!!"
Or, worse, some piece of code could have changed the prototype for String (or any other object type) somewhere outside of your file. Try this in a browser console:
String.prototype.all = String.prototype.all || "This is beyond evil.";
// 'This is beyond evil.'
var spam = "spam"
// undefined
spam.all
// 'This is beyond evil.'
So JSLint doesn't, by default, check for properties on objects by names. Especially for objects that could live outside of your file's context (because JSLint lints file-by-file), it simply can't know what's happened to an object's properties and identify what's valid and what isn't.
(That's what TypeScript is for, btw.)
Unless you tell JSLint how!! -- the JSLint property directive ftw
Or you can use the JSLint property directive, which does exactly what you want, if you're willing to do some work.
If you put the property directive at the top of your file, JSLint will show errors for any properties that are used by objects on the page that aren't in that list.
For instance, try this on the official JSLint.com page:
/*property
log
*/
/*jslint browser, devel */
function mySpam() {
var spam = document.all;
console.log(spam);
}
See how I'm using document.all but all isn't in the property directive? It's going to error for me.
1. Unregistered property name 'all'.
var spam = document.all;
You might be saying, "But it will take me FOREVER to get all the good properties from my 3000 line file I'm linting into that directive!!"
Not so! Here's a tip: Paste your file, even unlinted, into JSLint.com. It will create a property directive for you in its report.
Here's one I made from AngularJS' [sic] route.js in just a few seconds:
/*property
$$minErr, $evalAsync, $get, angularVersion, caseInsensitiveMatch, create,
defaultPrevented, eagerInstantiationEnabled, extend, info, isArray,
isDefined, isObject, isUndefined, length, module, noop, originalPath,
otherwise, preventDefault, provider, redirectTo, reload, reloadOnSearch,
reloadOnUrl, routes, run, substr, when
*/
Alphabetical, even.
Now just remove the ones you don't want and presto! You'll catch everything you need.
Is this a little tedious, and will it take a little massaging/training on files that use document properly? Yes, but, again, in a dynamic language, this is close to the best you can hope for with file-by-file linters.
NOTE: If this doesn't solve your issue, however imperfectly, that's when we need to see more of your files and hear more precisely what problem you're trying to solve in practice.
I am using #testing-library/vue and run the tests within a build step of Sublime Text. The error output uses prettyDom and isn't very legible in the output window:
Example Output in Build Results window:
TestingLibraryElementError: Unable to find a label with the text of: /val1/
[36m<div[39m
[33mclass[39m=[32m"Cell"[39m
[33mdata-v-1cdb88a0[39m=[32m""[39m
[33mstyle[39m=[32m"width: 40%;"[39m
[36m>[39m
[36m<div[39m
[33mclass[39m=[32m"Label"[39m
[33mdata-v-1cdb88a0[39m=[32m""[39m
[36m>[39m
[0mTest Cat #1[0m
[36m</div>[39m
[36m<div[39m
[33mattrs[39m=[32m"[object Object]"[39m
[33mdata-v-088d7313[39m=[32m""[39m
[33mdata-v-1cdb88a0[39m=[32m""[39m
[33mform[39m=[32m"[object Object]"[39m
[33mon[39m=[32m"[object Object]"[39m
[33mprops[39m=[32m"[object Object]"[39m
Is there a way to turn off the syntax highlighting with an environment variable like you can to extend the output length?
Syntax highlighting is handled by the editor displaying the text.
In Sublime Text you can effectively remove – turn off if you like – the syntax highlighting of the current file / buffer by changing the syntax to Plain Text.
You can do that by choosing Plain Text after clicking on the active syntax name on the right of the Status Bar or from the View --> Syntax menu, or by opening the Command Palette and selecting the Set Syntax: Plain Text command.
prettyDOM takes the same options as pretty-format. One of those options is "highlight". In pretty-format it seems to be false by default, but in prettyDOM I found it's true by default. You can disable it like this:
prettyDOM(myDom, undefined, {highlight: false})
The apparent answer is to get Sublime Text to display the colors in the build window by using the ANSIescape plugin:
https://forum.sublimetext.com/t/ansi-color-codes-in-build-output/11296/16
https://packagecontrol.io/packages/ANSIescape
You can set the COLORS environment variable to false to turn off colourisation. See https://testing-library.com/docs/dom-testing-library/api-debugging/
Although your question relates to the build results window in Sublime, this is a common problem in other places where the colour codes make it hard to see the actual debug output (in my case a Jenkins console output when tests fail).
I have updated jade to latest version, and started seeing this message in console
You should not have jade tags with multiple attributes
It is mentioned as feature, here
0.33.0 / 2013-07-12
Hugely more powerful error reporting (especially with compileDebug set explicitly to true)
Add a warning for tags with multiple attributes
and I see it in the code.
https://github.com/visionmedia/jade/blob/a38aa552f6f53554ac5605299b6b8c7e07cbdf1f/lib/parser.js#L662
But, what does it really signify. When will I get this warning. For example, when will I get error based on the below code (It works without warning, but to like to know when will I get error so that I can compare with my code)
mixin link(href, name)
a(class=attributes.class, href=href)= name
a(href=href, attributes)= name
+link('/foo', 'foo')(class="btn")
Multiple "attributes" doesn't mean what you probably think it means. It's not an HTML attribute as we know it, but a token of type "attribute".
Example:
a(href="#WAT").some-class(title="WAT")
Note how I have two attribute sections, each with one attribute.
Better put them in one attribute section:
a(href="#WAT", title="WAT").some-class
(I found this question through googleing this warning as one of the first results because I wanted to get rid of it ...)
The accepted answer above did not help me in the following case, but it shows how one can get rid of the warning without loosing the attributes functionality
(it does not provide an answer to why it works this way):
// using mixins similar to +link(param1,param2) above where 'data' and 'class'
// below are not named mixin params
// OK (without a warning):
+link("foo", data="true")(class="bar")
// WARNING is shown:
+link("foo")(class="bar")(data="true")
// ERROR on compiling:
+link("foo", class="bar", data="true")
(I'm sorry to create so much misunderstandings as shown in the comments below and hope my last edit here clarifies it to be a valid, although slightly more general, answer/help for those docpad warnings)
I have some big set of different javascript-snippets (several thousands), and some of them have some stupid errors in syntax (like unmatching braces/quotes, HTML inside javascript, typos in variable names).
I need a simple way to check JS syntax. I've tried JSLint but it send too many warnings about style, way of variable definitions, etc. (even if i turn off all flags). I don't need to find out style problems, or improve javascript quality, i just need to find obvious syntax errors. Of course i can simply check it in browser/browser console, but i need to do it automatically as the number of that snippets is big.
Add:
JSLint/JSHint reports a lot of problems in the lines that are not 'beauty' but working (i.e. have some potential problems), and can't see the real problems, where the normal compiler will simply report syntax error and stop execution. For example, try to JSLint that code, which has syntax errors on line 4 (unmatched quotes), line 6 (comma required), and line 9 (unexpected <script>).
document.write('something');
a = 0;
if (window.location == 'http://google.com') a = 1;
document.write("aaa='andh"+a+"eded"');
a = {
something: ['a']
something2: ['a']
};
<script>
a = 1;
You could try JSHint, which is less verbose.
Just in case anyone is still looking you could try Esprima,
It only checks syntax, nothing else.
I've found that SpiderMonkey has ability to compile script without executing it, and if compilation failed - it prints error.
So i just created small wrapper for SpiderMonkey
sub checkjs {
my $js = shift;
my ( $js_fh, $js_tmpfile ) = File::Temp::tempfile( 'XXXXXXXXXXXX', EXLOCK => 0, UNLINK => 1, TMPDIR => 1 );
$| = 1;
print $js_fh $js;
close $js_fh;
return qx(js -C -f $js_tmpfile 2>&1);
}
And javascriptlint.com also deals very good in my case. (Thanks to #rajeshkakawat).
Lots of options if you have an exhaustive list of the JSLint errors you do want to capture.
JSLint's code is actually quite good and fairly easy to understand (I'm assuming you already know JavaScript fairly well from your question). You could hack it to only check what you want and to continue no matter how many errors it finds.
You could also write something quickly in Node.js to use JSLint as-is to check every file/snippet quickly and output only those errors you care about.
Just use node --check filename
Semantic Designs' (my company) JavaScript formatter read JS files and formats them. You don't want the formatting part.
To read the files it will format, it uses a full JavaScript parser, which does a complete syntax check (even inside regular expressions). If you run it and simply ignore the formatted result, you get a syntax checker.
You can give it big list of files and it will format all of them. You could use this to batch-check your large set. (If there are any syntax errors, it returns a nonzero error status to a shell).
Is there an option to and/or how do I suppress errors like the following?
175,14:['tracker'] is better written in dot notation.
If it's a feature and not a bug, place this at the top of your file.
/*jshint sub:true*/
If it's a bug, you should refactor your code
foo['tracker'] = bar // from this...
foo.tracker = bar; // to this!
Good post on the reasons here: https://stackoverflow.com/a/2001410/94668
As suggested by: #ThorSummoner you can use below in your .jshintrc file
"sub": true
In JSHint 1.0.0 and above you have the ability to ignore any warning with a special option syntax. The identifier of this warning is W069.
This means you can tell JSHint to not issue this warning with the /*jshint -W069 */ directive.
You can even wrap several lines of code and then reenable the warning as the example below (with a note to future you why it was a good idea):
/*jshint -W069 */
/*Disable Warning Justification:
Using bracket notation so Google Closure Compiler
ADVANCED_OPTIMIZATIONS will keep the original property names. */
obj['prop1'] ='foo';
obj['prop2'] ='bar';
/*jshint +W069 */
I assume you are asking about Dreamweaver or another editor.
Dreamweaver
You may go to Edit -> Preferences -> Linting
Select JS in the dropdown and hit Edit & Apply changes
Find
"sub": false,
and change that to true. Save the file and that notice will disappear.
If you have OTHER Linting things you wish to edit, you can find a helpful list of them all at https://jshint.com/docs/options/