Validation of Javascript in VisualStudio using google closure
A recently seen topic about css validation in Visual Studio spurred on to write a similar thing about Javascript validation.
When javascript in a web project takes a large enough share of the code, and client scripts grow beyond the scope of inline scripts with one or two lines of jquery plug-in calls, the question of checking their validity arises quite clearly (even for .net developers who are quite far from js basically :)).
Ideally, I wanted to have a compiler that, when building a project, would also “compile” javascript, with the usual indication of errors / warnings in the VS window.
For such a compilation, a number of utilities have already been written, and I even made a small review of existing solutions.
In short, you can check javascript using jslint , jshint and google closure . It is not hard to guess that the latter have the widest possibilities, and at least a couple of ready - made solutions exist for its integration into Visual Studio.
In this article I will talk about another google closure integration utility in Visual Studio, namely jsvalidator , a small open-source project that I wrote after the above analysis.
The key difference of my implementation is the ease of integration and the ability to configure the display of certain types of alerts.
')
JsValidator is a utility that runs on a post-build-event with a json-like configuration file that checks javascript using the google closure java-library. This also implies the first requirement - for the utility to work, you need java installed on your computer (with java.exe added to the system paths (system PATH)).
After integrating the utility on each build in your Visual Studio there will be something like:
(in this case, the utility tells us about the undeclared variable asd , double-clicking on the error will open the js-file on the line with the error, as we are used to).
To integrate jsvalidator in a project, it is enough to install the JsValidator nuget package. If you are not using nuget, then you can do all the steps that the package will do automatically by hand:
Above, I gave an example of a simple configuration file consisting of one line. Real configs are not much more complicated. Here is an example of one of them:
I will decipher what each of the parameters is responsible for:
I want to focus on the parameter Warnings , because it was he who was missing in other implementations and pushed to write a bicycle.
Google Closure sorts all “suspicious areas” of JavaScript for errors and warnings. Sometimes you want to translate some warnings into error status so that they cannot be ignored (there are usually quite a lot of warning signals generated, and there is usually no point in analyzing / correcting them all). For this, there is an option Warnings . As mentioned above, if the warning falls under one of the included regexps, it goes into the category of “error”.
There are some other options that are not mentioned in the example, but may be useful:
There are some other parameters that mirror the parameters of the closure compiler. Changing these parameters is usually not required; they are described in more detail on the project page (CompilationLevel, WarningLevel, Ccargs).
If it is useful to someone, please write down the success-story and the config parameters used :)
When javascript in a web project takes a large enough share of the code, and client scripts grow beyond the scope of inline scripts with one or two lines of jquery plug-in calls, the question of checking their validity arises quite clearly (even for .net developers who are quite far from js basically :)).
Ideally, I wanted to have a compiler that, when building a project, would also “compile” javascript, with the usual indication of errors / warnings in the VS window.
For such a compilation, a number of utilities have already been written, and I even made a small review of existing solutions.
In short, you can check javascript using jslint , jshint and google closure . It is not hard to guess that the latter have the widest possibilities, and at least a couple of ready - made solutions exist for its integration into Visual Studio.
In this article I will talk about another google closure integration utility in Visual Studio, namely jsvalidator , a small open-source project that I wrote after the above analysis.
The key difference of my implementation is the ease of integration and the ability to configure the display of certain types of alerts.
')
JsValidator is a utility that runs on a post-build-event with a json-like configuration file that checks javascript using the google closure java-library. This also implies the first requirement - for the utility to work, you need java installed on your computer (with java.exe added to the system paths (system PATH)).
After integrating the utility on each build in your Visual Studio there will be something like:
(in this case, the utility tells us about the undeclared variable asd , double-clicking on the error will open the js-file on the line with the error, as we are used to).
To integrate jsvalidator in a project, it is enough to install the JsValidator nuget package. If you are not using nuget, then you can do all the steps that the package will do automatically by hand:
- Download library binaries and unzip for example in the $ (SolutionDir) / JsValidatorBin folder.
- Create a configuration file in an ASP.Net project (for example, in Scripts / jsvalidator / config.js ). In the simplest case, it might look like this:
{ "inputs": [ "../_test.js" ] }
The path to the _test.js file can be replaced with the path to any js-file of your project (or folder with js-files). All paths should be relative to the location of the config.js configuration file. - Add a JsValidator as a post-build-event (Project / Properties / Build events / Post-build event command line) to your asp.net project. The post-build-event string may look like this:
"$(SolutionDir)JsValidatorBin\jsvalidator.exe" "$(ProjectDir)Scripts\jsvalidator\config.js"
(if you unpacked jsvalidator in ways other than examples, then the path will need to be fixed) - That's all! Compile your project and make sure that there are no errors in your javascript :)
Above, I gave an example of a simple configuration file consisting of one line. Real configs are not much more complicated. Here is an example of one of them:
{ inputs: [ "../../Scripts/zw_Runtime.js", "../../Scripts/UC/", "../../Scripts/jquery.common.js"], externs: ["//jquery-1.7.js"], IgnoreAllWarnings: "true", Warnings: [".* is never defined"] } I will decipher what each of the parameters is responsible for:
- inputs (array of strings) . Specifies paths to files / folders to check. The simplest, most obvious and necessary option :)
- externs (array of strings) . Specifies the external libraries needed for validation (jquery, mootols, etc.). Analogue of the externs parameter in google closure. Google has a number of “documented” versions of popular libraries prepared to be connected as external. Libraries from this source can be used with the prefix "//". In the example above, we say that jquery version 1.7 can be used in our files.
- IgnoreAllWarnings (bool) . “True” or “false” (default is “false”). Found “warnings” are ignored (only found “errors” are displayed)
- Warnings (array of strings) . Regexp list; suitable for regexps "warnings" are transferred to the status of "errors".
I want to focus on the parameter Warnings , because it was he who was missing in other implementations and pushed to write a bicycle.
Google Closure sorts all “suspicious areas” of JavaScript for errors and warnings. Sometimes you want to translate some warnings into error status so that they cannot be ignored (there are usually quite a lot of warning signals generated, and there is usually no point in analyzing / correcting them all). For this, there is an option Warnings . As mentioned above, if the warning falls under one of the included regexps, it goes into the category of “error”.
There are some other options that are not mentioned in the example, but may be useful:
- TreatNoJavaAsWarning (bool) . Values ​​are "true" or "false" (by default - "false", that is, if there is no Java installed on the computer, an error will be generated)
- IgnoreWarnings (array of strings) . The list of regexps suitable for rehexps "warnings" are discarded.
There are some other parameters that mirror the parameters of the closure compiler. Changing these parameters is usually not required; they are described in more detail on the project page (CompilationLevel, WarningLevel, Ccargs).
If it is useful to someone, please write down the success-story and the config parameters used :)
Source: https://habr.com/ru/post/134344/
All Articles