We have determined our rules, which should be used for JavaScript code, with ESLint. Now we want to integrate ESLint to SonarQube as we did it before the same way with Checkstyle for JavaCode.
Under the following link it is described why SonarQube doesn't want to provide a plugin for ESLint:
http://www.sonarqube.org/sonarqube-javascript-plugin-why-compete-with-jslint-and-jshint/
Is there still no plugin fir ESLint in SonarQube? Isn't this part of a marketing strategy? There is also a plugin for Checkstyle, FindBugs etc... Why does SonarQube suddenly stop to support the integration of other code analysing tools?
Yes, there is still no plugin for ESLint, and this is part of the strategy, but in the other direction.
In fact, our first plugins were for external analyzers, and over time we realized that simply aggregating other tools' results didn't truly serve the community because that community was coming to us with rule bugs, requests and suggestions for improvement - and all we could do was refer them on the tools' makers.
So we started writing our own rules instead for better responsiveness and, we believe, enhanced accuracy.
I urge you to take the rules you feel are missing to the SonarQube Google Group
Edit The strategy has come full circle. SonarJS now imports ESLint reports.
I have not tried it yet, but I've just discovered this plugin that seems to be very promising for any front end project:
https://github.com/groupe-sii/sonar-web-frontend-plugin
It may worth giving a try
You have a good option here:
https://github.com/sleroy/SonarEsLintPlugin
From the docs:
• Install Node.js
• Install EsLint (3+) with npm install -g eslint, or ensure it is installed locally against your project
• If you're installing globally, find the path to EsLint and copy it - will be similar to C:\Users\
[Username]\AppData\Roaming\npm\node_modules\eslint\bin\eslint.js on Windows
• Copy .jar file (downloaded from https://github.com/sleroy/SonarEsLintPlugin/releases page) to SonarQube extensions folder
• Restart SonarQube server
• Browse to SonarQube web interface, login as Admin, hit up Settings
• Hit the Rules tab, then the EsLint rule set, then apply it to your project - alter rule activation as required
I came across a similar requirement and the following are the steps that I followed to achieve the ESLint report output integration into the Sonarqube dashboard:
Switch to the project directory.
Run: npx eslint <source_code_to_be_scanned> --format json --output-file <file_name>.json
For e.g. npx eslint ./src/**/*.js --format json --output-file eslint-result.json
Cope the relative path of the generated report.
Add an additional property in your sonar-project.properties file as below:
sonar.eslint.reportPaths=app/eslint-result.json
Perform the scan
Output: I was able to see the expected output within my Sonarqbue dashboard.
I hope some of you find it helpful and save a bit of time.
Related
I'm attempting to use PostCSS to fix the problem where 100vh doesn't account for the browser/navigation bar on mobile devices.
https://github.com/Faisal-Manzer/postcss-viewport-height-correction
The problem is, I have no idea how to set it up and the instructions assume I know how. I have very little experience with JavaScript and don't use any frameworks or know how to, I just do everything in VS Code with no plugins.
I installed the PostCSS extension in VS Code but am unsure what to do next.
The installation says:
"And then add this javascript to public/index.html (for React), or add to template.html (for Preact)."
I don't use React (I don't think?), so what do I do instead?
Then it says:
"Check you project for existed PostCSS config: postcss.config.js in the project root, "postcss" section in package.json or postcss in bundle config.
If you already use PostCSS, add the plugin to plugins list:"
Would postcss.config.js be in my root folder? Am I supposed to create this file?
It then says to do this:
module.exports = {
plugins: [
+ require('postcss-viewport-height-correction'),
require('autoprefixer')
]
}
I added that to my .js file (Or does it go in the css file?), and am getting an error "module is not defined."
Could someone walk me through this as if I had no idea what I'm doing and have only been using JavaScript and VS Code for a week? Because that's where I'm at.
I'm on Windows if that makes a difference.
Part of the instructions say to do:
npm install --save postcss-viewport-height-correction
I don't know where to enter this command. I've come across similar instructions several times, and looking up "How to do npm install" doesn't produce any results. I've largely been avoiding using frameworks and extensions and plugins with JavaScript because I can never figure out how to use them, and every guide I can find assumes I already know what it all means.
Might be a long winded answer, but I'll try to respond to everything.
PostCSS is a JS-based tool for transforming styles with JS plugins. Typically, you use it as a plugin into your front-end build tool such as Webpack, Rollup, etc. You can also use it as a CLI app, manually running your build.
I just do everything in VS Code with no plugins.
Which editor you use is irrelevant. How are you building this content? Is it just plain HTML and CSS files?
I installed the PostCSS extension in VS Code
That extension is just for getting your editor on the same page as your PostCSS config. For example, you might write some CSS with your PostCSS config that will look like totally invalid CSS to your editor, and it would throw errors at this. That extension ensures it follows the same altered rules as your CSS now does, since you're using a tool that changes the rules.
Would postcss.config.js be in my root folder? Am I supposed to create this file?
Yes
I added that to my .js file (Or does it go in the css file?), and am getting an error "module is not defined."
JS, but it's throwing errors because you need to install it
Part of the instructions say to do:
npm install --save postcss-viewport-height-correction
I don't know where to enter this command.
From your terminal. NPM (and Yarn, if you run across it) is a CLI tool for installing Node packages, like PostCSS here.
Here are the instructions for installing Node & NPM: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm
What exactly should I put in .npmignore?
Tests? Stuff like .travis.yml, .jshintrc? Anything that isn't needed when running the module (except the readme)?
I can't find any guidance on this.
As you probably found, NPM doesn't really state specifically what should go in there, rather they have a list of ignored-by-default files. Many people don't even use it as everything in your .gitignore is ignored in npm by default if .npmignore doesn't exist. Additionally, many files are already ignored by default regardless of settings and some files are always excluded from being ignored, as outlined in the link above.
There is not much official on what always should be there because it is basically a subset of .gitignore, but from what I gather from using node for 5-ish years, here's what I've come up with.
Note: By production I mean any time where your module is used by someone and not to develop on the module itself.
Pre-release cross-compiled sources
Pros: If you are using a language that cross-compiles into JavaScript, you can precompile before release and not include .coffee files in your package but keep tracking them in your git repository.
Build file leftovers
Pros: People using things like node-gyp might have object files that get generated during a build that never should go into the package.
Cons: This should always go into the .gitignore anyway. You must place these things inside here if you are using a .npmignore file already as it overrides .gitignore from npm's point of view.
Tests
Pros: Less baggage in your production code.
Cons: You cannot run tests on live environments in the slim chance there is a system-specific failure, such as an out of date version of node running that causes a test to fail.
Continuous integration settings/Meta files
Pros: Again, less baggage. Things such as .travis.yml are not required for using, testing, or viewing the code.
Non-readme docs and code examples
Pros: Less baggage. Some people exist in the school-of-thought where if you cannot express at least minimum viable functionality in your Readme, your module is too big.
Cons: People cannot see exhaustive documentation and code examples on their own file system. They would have to visit the repository (which also requires an internet connection).
Github-pages objects
Pros: You certainly don't need to litter your releases with CNAME files or placeholder index.htmls if you use your module serves double-duty as a gh-pages repository as well.
bower.json and friends
Pros: If you decide to build in your dependencies prior to release, you don't need the end-user to install bower then install more things with that. I would, personally, keep that stuff in the package. When I do an npm install, I should only be relying on npm and no other external sources.
Basically, you should ever use it if there is something you wish to keep out of your npm package but checked-in to your module's repo. It's not a long list of items, but npm would rather build in the functionality than having people stuck with irrelevant objects in their package.
I agree with lante's short and syntetic answer and SamT's big answer:
You should not include your tests in your package.
Your package should only contains production runtime files.
That will make your package more straightforward and faster to be dowloaded.
My contribution to those answers:
.npmignore is the blacklist way to achieve package file selection. But in a more practical way, you can whitelist files you need to include in your package using the files field in your package.json:
{
"files": [
"lib/",
"index.js"
]
}
I think that's simpler, future proof and have better semantics ;)
Just to clarify, anytime someone do npm install your-library, npm will download all source files that the package includes. Those files that were included in the .npmignore file in the source code of the package your-library will be excluded when publishing the lib, so users of your-library won't download them.
Know that people installing your library will need just your library running, anything else will be not necessary.
For example, when someone installs a library, its probably that he/she doesn't care about your .travis.yml or your .jshintrc files, or even some images, Grunt files, documentation, etc.
.npmignore could let your npm package to have less files, and faster to be downloaded
Don't include your tests. Oftentimes tests are like 5x the size of the actual codebase. As long as your tests are on Github, etc, that's good enough.
But what you absolutely should do is test your NPM package in its published format. Create some smoke tests that reside in the actual codebase, but are not part of the test suite.
You can read about testing your package after tarballing it, here:
https://github.com/ORESoftware/r2g
How to test an `npm publish` result, without actually publishing to NPM?
Please see the edit below
I have used the following package as a base for my VS Project ->
https://github.com/AngularClass/angular2-webpack-starter
Everything worked nicely in Visual Studio code, I then tried to convert it to a Visual Studio 2017 Project (node.js web)
Now some problems appeared
VS seems to install TypeScript definitions into a special folder C:\Users\MyUser\AppData\Local\Microsoft\TypeScript\node_modules\#types
Additionally I included #types/node in my package.json which resulted in the appropriate node_modules folder.
now VS complains with error code TS4090 (Conflicting defintions for 'node').
Is there a possibility apart from deleting the folder in \AppData to tell VS which #types it should use?
The whole integration of TypeScript isn't really clear to me...
Does MSBuild recognize an existing tsconfig.json? or would I have to configure it in in the project-file as seen here?
EDIT
I just noticed that I was actually editing a .js file.
As soon as I changed the extension to .ts every warning and error vanished.
I also got many typescript errors (like TS2307, can't find module '#angular/core') before changing the extension from .js to .ts
The file just did an import (from node)
import * as fs from 'fs';
Could anyone explain why I got this errors?
Why a JS files causes 200+ typescript errors (some don't even seem related to the import from above)?
EDIT2
the errors which occur are
TS2403 - Subsequent Variable declarations must have the same type.
TS2300 - Duplicate identifier 'PropertyKey'
TS4090 - Conflicting definitions for 'node' found (paraphrasing: found in ./node_modules and C:\Users\MyUser\AppData\Local\Microsoft\TypeScript\node_modules\#types
All the errors are caused by d.ts files in C:\Users\MyUser\AppData\Local\Microsoft\TypeScript\node_modules\#types or C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TypeScript\lib.es6.d.ts
like Bowden Kelly noted, this seems the cause for this problems seems to be the definition files MS put in here C:\Users\MyUser\AppData\Local\Microsoft\TypeScript\node_modules\#types, as soon as I install my own definition files in ./node_modules VS finds both definitions (if present) when editing JS files.
So the solution would either be:
doing it the MS Way
somehow exclude MS Directory
This is a BUG related in https://github.com/Microsoft/TypeScript/issues/14565
I was able to eliminate the errors by enabling
For JavaScript, try to uncheck/disable the "new JavaScript language service" under Tools > Options > Text Editor > JavaScript/TypeScript > Language Service. This seemed to help me when I opened random JavaScript files and the error window would go crazy.
Regarding the Angular 2 errors (cannot find module #angular/core), if there is a tsconfig.json in the project directory both Visual Studio and the TS compiler will use that. If you close an reopen the solution everything on the TypeScript tab of project properties should be disabled.
Once you know tsconfig.json is working, if you are using TS 2.x the compiler should find and use the types that come with angular 2 under node_modules/#angular/core/index.d.ts, unless you have a setting in tsconfig that overrides this like types: [].
I have still not been able to figure out 100% what is going on in Visual Studio Errors window since I still get sporadic unjustified errors (I know this because I can still compile). I do know that the Visual Studio TypeScript Language Service is what controls errors and intellisense in the Visual Studio IDE and it is tied to a specific version of TypeScript (2.1 in VS 2017). The errors have always caused problems in both VS 2015 and now VS 2017 also. I think it comes down to the inner workings of the extremely undocumented TypeScript Virtual Projects, for which I have still not found a purpose.
These links are useful reading:
http://blog.angular-university.io/typescript-2-type-system-how-do-type-definitions-work-in-npm-when-to-use-types-and-why-what-are-compiler-opt-in-types/
http://www.typescriptlang.org/docs/handbook/tsconfig-json.html#types-typeroots-and-types
https://github.com/Microsoft/TypeScript/issues/14540
The definition files installed to C:\Users\MyUser\AppData\Local\Microsoft\TypeScript\node_modules\#types are used for giving JavaScript IntelliSense only. If you have TypeScript in your project or a project configured with a tsconfig.json, you need to fetch your own .d.ts files and store them in your project. Luckily this project comes with all the .d.ts files you need already in the package.json a simple npm install should do the trick.
I can tell you that the conflicting definitions with 'node' are likely due to having 2 copies of the node.d.ts file. If you manually installed one yourself, on top of the one included in the projects package.json, then you'll get those errors.
I'm not certain about the TS errors you are getting in your JavaScript file. Can you show me an example of one of the errors and a snippet of the code causing it?
Also you probably don't want integration with MSBuild as this project is already setup to run with npm scripts + webpack. You should check out this plugin: https://marketplace.visualstudio.com/items?itemName=MadsKristensen.NPMTaskRunner
Finally I don't think you want to be inside a Node.js web project. For this project, you are probably best off just opening the folder in VS. To do that just use File > Open > Folder... and navigate to your root folder. This will give you all the editing tools you need without any MSBuild or VS project structure. Considering this project wasn't designed to take advantage of any of those features, it'll probably be easier just to ignore them for now.
Please let me know what other issues you run into.
FYI, this has been fixed in Visual Studio 17.2 🙂
VJET is almoust working for me, I can get code completion in the same file and for basic Node.js modules (using NodejsTL) but for new modules(my modules) or modules installed with npm an increasing number of errors plagues my "Problems" tab in Eclipse. It is there any way to have clean "builds" and get rid of all warnings and errors?
Vjet currently doesn't understand user defined modules. There are a three solutions to fix this... (1)a type library can be added to support more modules. (2)Vjet can be extended to support npm modules there is a enhancement request open for this. (3)There is a way to disable errors and warnings as well. You can provide disable errors and warnings at the project or workspace level. See preferences -> vjet -> code compliance -> errors and warnings. Thanks for the feedback.
Here is the enhancement request you should vote for to get VJET to understand nodejs user defined modules - https://www.ebayopensource.org/jira/browse/VJET-88
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How do I install JSLint on Ubuntu?
I downloaded the source jsl-0.3.0-src.tar.gz from http://www.javascriptlint.com/download.htm and then extracted it to a dir called jsl-0.3.0 on my Desktop. I then moved it to /usr/local/bin which I have read is my PATH. I also want to mention that I have Rhino 1.7 installed already.
When I try to run jsl from terminal I got the following message:
No command 'jsl' found, did you mean:
Command 'jls' from package 'sleuthkit' (universe)
Command 'js' from package 'rhino' (main)
Command 'sl' from package 'sl' (universe)
Command 'fsl' from package 'fsl' (multiverse)
jsl: command not found
So I how do I properly install JSLint?
How to install JSLint on Ubuntu:
Install nodejs (includes npm, the Node Package Manager):
sudo apt-get install nodejs
Install node-jslint. either globally:
sudo npm install -g jslint
or locally, and include it in $PATH:
npm install jslint
and add this line to your.bashrc (adjust version number as appropriate)
alias jslint='~/.npm/jslint/0.1.8/package/bin/jslint.js'
Here are the instructions I followed to have jslint working on Ubuntu 10.10/Vim 7.3 (and Mac OS X).
EDIT
So, I've just spotted a mistake in the given link. Here are the correct steps (assuming you have already downloaded and unpacked the archive to your desktop:
$ cd /path/to/jsl-0.3.0/src
$ make -f Makefile.ref
$ cp Linux_All_DBG.OBJ/jsl /usr/local/bin/jsl
At that point you can open a new terminal window and type $ jsl to display a quick help or invoke it from Vim or directly on a file in the terminal.
END EDIT
/usr/local/bin is not your "PATH", it's only one of the many directories that can be part your PATH environment variable. $ echo $PATH will tell you what these directories are and thus where you can put the jsl executable. You can also put it in another place and add an alias to your .bashrc.
Why do you expect to be able to run jslint from rhino?
You said you just copied the source to /usr/local/bin. You need to compile it. Follow the build instructions in the README.html
Unix
Use 'gmake -f Makefile.ref' to build. To compile optimized code, pass BUILD_OPT=1 on the gmake command line or preset it in the environment or Makefile.ref. NOTE: Do not attempt to use Makefile to build the standalone JavaScript engine. This file is used only for building the JS-engine in the Mozilla browser.
Each platform on which JS is built must have a *.mk configuration file in the js/src/config directory. The configuration file specifies the compiler/linker to be used and allows for customization of command-line options. To date, the build system has been tested on Solaris, AIX, HP/UX, OSF, IRIX, x86 Linux and Windows NT.
Most platforms will work with either the vendor compiler or gcc. (Except that HP builds only work using the native compiler. gcc won't link correctly with shared libraries on that platform. If someone knows a way to fix this, let us know.)
If you define JS_LIVECONNECT, gmake will descend into the liveconnect directory and build LiveConnect after building the JS engine.
To build a binary drop (a zip'ed up file of headers, libraries, binaries), check out mozilla/config and mozilla/nsprpub/config. Use 'gmake -f Makefile.ref nsinstall-target all export ship'
As for your question about the difference. It says on the download page that one is written in JavaScript itself.
We all stand on the shoulders of giants. I would like to especially acknowledge Douglas > Crockford's work on JSLint. This lint is itself written in JavaScript and is an
interesting and rather sophisticated script. Crockford's ideas about good coding
practices served as a springboard for many of these lint rules.
Look at your "jsl-0.3.0/src/README.html" file. This says:
1) You have a "source package". You need to "build" it (with a C compiler), then install your build.
2) This is more than just JSLint. It's an entire Javascript engine. Per the README:
This is the README file for the JavaScript Reference (JSRef, now
better known as SpiderMonkey) implementation. It consists of build
conventions and instructions, source code conventions, a design
walk-through, and a brief file-by-file description of the source.
JSRef builds a library or DLL containing the JavaScript runtime
(compiler, interpreter, decompiler, garbage collector, atom manager,
standard classes). It then compiles a small "shell" program and links
that with the library to make an interpreter that can be used
interactively and with test .js files to run scripts. The code has no
dependencies on the rest of the Mozilla codebase.
3) Here is Douglas Crockford's original JSLint page:
http://www.jslint.com/
4) And here is a a good example of how you might use JSLint locally, on your own PC:
http://code.google.com/p/js-ria-tools/wiki/JSLint
5) You say you already have Rhino - good. In Google, you'll find many obsolete links to www.jslint.com/rhino. Here's why - along with links to current Rhino-related info:
http://hustoknow.blogspot.com/2011/02/jslint-and-rhino-support.html
'Hope that helps!