Google Closure Library – Compilation Warnings - javascript

I've been using the Google Closure Compiler for a few years but I haven't played with the actual Closure Library that much.
When I compile my app, I get the following warnings. The referenced code is in the library itself, not in my files. I'm wondering whether I should do something to fix them or just wait for the Closure Library contributors to do that.
/Users/Jan/.../closure-library/closure/goog/dom/dom.js:673:
WARNING - Property type never defined on attributes
delete attributes.type;
^
/Users/Jan/.../closure-library/closure/goog/dom/dom.js:2396:
WARNING - assignment to property getFrameContentDocument of goog.dom.DomHelper.prototype
found : function ((Element|null)): Document
required: function (this:goog.dom.DomHelper, (HTMLFrameElement|HTMLIFrameElement|null)): HTMLDocument
goog.dom.DomHelper.prototype.getFrameContentDocument =
^
/Users/Jan/.../closure-library/closure/goog/fx/animation.js:255:
WARNING - mismatch of the stop property type and the type of the property it overrides from superclass goog.fx.TransitionBase
original: function (this:goog.fx.TransitionBase, boolean=): ?
override: function (this:goog.fx.Animation, boolean): ?
goog.fx.Animation.prototype.stop = function(gotoEnd) {
^
Nothing breaks as far as I can tell. The warnings do not pop for just one project but I do use the library the same way for all.

Related

ESlint rule that detects that a variable and a function has the same name in Javascript?

I happened to name a variable the same as a function in Node.js. This did not go very well, Node 10 did not like it. And since this was a hook function (not called from the UI of the app) it took some time before I discovered what went wrong.
Is there some ESLint rule that can discover these type of bugs? This is under Firebase and and ESLint is run during the deploy to production server.
The actual conflicting use of the variable name was in the same block, something like this: const a = a(x).
I don't think a tool like this could exist for JavaScript, as JavaScript doesn't really disambiguate the type of object assigned to the variable.
function a() {
}
... is basically equivalent to:
var a = function () {
};
Additionally, the value of a in this example can be reassigned later.
A linter may help you, and there may be some help in some IDEs, but they won't truly know the intention of the programmer.
There is a no-redeclare rule you can set in ESLint, which tells you the problematic line in your code.
/*eslint no-redeclare: "error"*/
function a() {}
const a = a();
=> 4:5 error 'a' is already defined no-redeclare
Also ESLint will raises an error with the standard configuration.
function a() {}
var a = a();
=> 4:5 error Parsing error: Identifier 'a' has already been declared
Of course, with const, you will get a syntax error with the line as well if you try to run your script.

Typescript compiler generates javascript even after compilation error

I am new to TypeScript and trying few basic stuffs. So I compile below app1.ts code
class Monster {
constructor(name, initialPosition) {
this.name = name;
this.initialPosition = initialPosition;
}
}
I believe we can add any properties to class Monster on fly like we can do in JS. So this.name and this.initialPosition should be a valid way. But as soon as I compile the code it has thrown below errors
app1.ts(3,14): error TS2339: Property 'name' does not exist on type
'Monster'.
app1.ts(4,14): error TS2339: Property 'initialPosition' does not exist
on type ' Monster'.
At this moment I thought we probably cannot add properties on fly (well, I got to know that we cannot do it like ECMA 6, we have to define properties - that's good) but when I check the generated JS it really surprised me. After compilation error it generated below JS code
var Monster = /** #class */ (function () {
function Monster(name, initialPosition) {
this.name = name;
this.initialPosition = initialPosition;
}
return Monster;
}());
I am a bit confuse. Why after compilation error it generated JS? What actually going on.
There are some types of errors relate to type checking that allow the compiler to emit JS. Just because the typescript compiler can't prove the program is typesafe does not mean it will not run. If the code can run it will be outputted to JS (so type errors allow emit, but syntactic ones do not)
There is a compiler option controlling this --noEmitOnError. You can read more here

How to disable warnings about 'this' and strict mode using JSHint?

I am writing a web app using AngularJS (v1.5) so I have some controllers, and in those controllers I am often declaring something like :
function myController($someDirectives, ...){
var ctrl = this;
// My code
}
The thing is when I JSHint my code, I get this warning message for all of my 'this' declared in controllers :
If a strict mode function is executed using function invocation, its 'this' value will be undefined.
I must precise that in my .jshintrc file, I set "strict":false.
Does anyone know how to disable this message in particular?
Thanks in advance.
set the configuration in .jshintrc file
{
"validthis": true // Tolerate using this in a non-constructor
}
You can always override jshint options in the code-block ie.
/* jshint validthis: true */
I had the same issue, with a very similar environment angular 1.5.5 always getting the same lint warning:
If a strict mode function is executed using function invocation, its 'this' value will be undefined.
I've changed the name of my component's main function starting with upper-case and the warning disappeared
function MyController($someDirectives, ...){
I'm having the same issue. I'm doing "indirect invocation" with the function in question, not "function invocation", and 'this' is referenced many times in the function body.
In my case, I was having so many of these "errors" that jsHint quit before scanning my whole script.
To get around this I put this at the top of my script-file:
/*jshint maxerr: 10000 */
It did not suppress the errors, but at least it allowed me to scroll down to see jsHint's analysis of the entire script.

What is the correct syntax for adding source and test sets to sonarqube gradle config?

I have a jhipster project with a sonarqube task defined in the project. We have built a react UI under the directory /src/main/ui/src/... and tests under /src/main/ui/src/test/... . Our sonarqube properties are as follows:
sonarqube {
properties {
property "sonar.host.url", "https://our_sonar_server"
property "sonar.projectKey", "MyProjectGroup:MyProject"
property "sonar.projectName", "MyProject"
property "sonar.login", sonarLogin
property "sonar.password", sonarPassword
property "sonar.links.scm", "https://mygithub/myProject.git"
property "sonar.links.scm_dev", "https://mygithub/MyProject.git"
property "sonar.links.ci", ciLink
if (pullRequest != null) {
property "sonar.analysis.mode", "preview"
property "sonar.github.pullRequest", pullRequest
property "sonar.github.repository", "MyProjectGroup/MyProject"
property "sonar.github.oauth", "my_oauth_hash"
property "sonar.github.endpoint", "https://mygithubapi/v3"
}
}
}
I currently, sonar only picks up the java which is under the standard /src/main/java. I have tried adding
property "sonar.sources", "src/main/ui/src/*.js"
property "sonar.test", "src/main/ui/src/test/**"
As well as a few variations. However, the jenkin build which invokes this via a shell step calling "./gradlew sonar -Pprod -x test" fails with an error like "invalid value" or similar. I have not been able to find an example for the correct syntax.
Edit: I was able to get the sonar build to pass in the PR using
property "sonar.sources", "src/main/ui/src"
property "sonar.test", "src/main/ui/src/test"
However, when checking the project on the sonar server, I'm still not seeing any of the javascript files being referenced.
After merging my last edit, the js files show up in sonarqube. The js tests are showing up as well, though they do not show any coverage percentage. Just the number of unit tests and how many pass. There's probably some more config necessary for that, but that wasn't really part of the original question.
After speaking with my manager, we decided to narrow the source sets to two subdirectories, "src/main/ui/src/app" and "src/main/ui/src/layouts" so that tests will not show up under source sets. The documentation suggests that you can add a comma separated list, so I created an external property and referenced those in the actual property:
ext.jsAppSrc = "src/main/ui/src/app, src/main/ui/src/layout"
ext.jsLayoutSrc = "src/main/ui/src/layout"
ext.jsTest = "src/main/ui/test"
...
property "sonar.sources", jsAppSrc, jsLayoutSrc
property "sonar.test", jsTest
The props evaluate correctly, but the sonar task fails with the error
Could not find method property() for arguments [sonar.sources, src/main/ui/src/app, src/main/ui/src/layout on org.sonarqube.gradle.SonarQubeProperties.
I then refactored to put the comma separated list in a single property, which then completed successfully.
ext.jsAppSrc = "src/main/ui/src/app, src/main/ui/src/layout"
ext.jsTest = "src/main/ui/test"
...
property "sonar.sources", jsAppSrc
property "sonar.test", jsTest

JavaScript JSHint - 'close' is defined but never used

I don't know why but some words that I use as function names get a lint error of being defined but never used.
For instance, the code below returns error:
// I am using AngularJS
$scope.close = close;
function close() {
/* Code here */
}
But this does not:
// I am using AngularJS
$scope.close2 = close2;
function close2() {
/* Code here */
}
The error is on the line function close(). Why is this such a special name? How can I mute this error?
(Note: Answer has been heavily edited)
Summary
John Papa says to use latedef in JSHint and, at least implicitly, to ignore JSLint issues. (latedef defined here.)
I believe there's a plays-nicely solution (see below), however, that includes the advantages of Papa's suggested style with code that lints in JSHint and JSLint.
JSHint is "wrong" not to complain about close2. JSLint catches it exactly like you'd expect.
close but not close2 is a JSHint problem
For what it's worth, if you paste your code (jslint formatted Pasteee with both close & close2 here) into JSLint.com, both close and close2 cause errors. If you're not seeing an error for close2, I'm guessing it's JSHint's problem, but it'd be more useful to see exactly what you're linting through JSHint (in context) to know for sure.
So close is not a special name to JSLint. I would like to see your "actual" code in context to see if JSLint would say something similar
Just to be clear, this breaks on JSLint.com:
/*jslint sloppy:true, white:true */
/*global $scope */
$scope.close2 = close2;
function close2() {
return "something";
}
That will produce 'close2' was used before it was defined. $scope.close2 = close2;
If you want to know why JSHint is, I believe, breaking, we can go JSHint code spelunking, but to answer your JSLint tag (at least) the behavior you're seeing isn't happening.
How to fix
See this SO answer on exactly what you're discussing here, where John Papa says to use latedef in JSHint. One way around the linting issue is to ignore Papa and define the function first, but, as you mention in your comment, below, that's not ideal.
So here's the best compromise I could come up with...
Declare, but don't define, variables that will hold functions.
Insert your Angular directive
Define your functions from 1.
That definitely mutes the JSHint error, since the code that caused it isn't there any more. If I was doing Angular and needed to follow Papa-style, that's what I'd do to keep Crockford's blessing.
Example:
(function () {
'use strict';
// 1. Declare your function names. Minimally spammy!
var theController;
// 2. Directive
angular
.module('myApp')
.controller('myAppCtrl', theController);
// 3. *Define* the functions. No `latedef` needed, and JSLint compliant.
// Keeps "the list of calls at the top of the page" and allows you to
// "jump to each definition if you need more details". QED? ;^)
theController = function () {
return "so jslint doesn't complain about empty blocks";
};
}());

Categories

Resources