gruntjs / grunt-contrib-jshint Goto Github PK
View Code? Open in Web Editor NEWValidate files with JSHint.
Home Page: http://gruntjs.com/
License: MIT License
Validate files with JSHint.
Home Page: http://gruntjs.com/
License: MIT License
Now that this task supports jshint reporters it seems to make sense to utilize dest
to output those reports to a file as suggested in #46. The jshint equivalent being:
$ jshint --reporter=checkstyle myfile.js > myreport.xml
This breaks backwards compatibility though as users (including this plugin's Gruntfile) does this currently:
jshint: {
all_files: [
'Gruntfile.js',
'tasks/**/*.js',
'<%= nodeunit.tests %>'
],
}
Which with this change would try and write the report to all_files
.
/cc @cowboy
@tkellen - do you remember why you use grunt.log.writeln
instead of grunt.log.error
here?
// Manually increment errorcount since we're not using grunt.log.error().
grunt.fail.errorcount++;
// Descriptive code error.
pos = '['.red + ('L' + e.line).yellow + ':'.red + ('C' + character).yellow + ']'.red;
if (e.code) {
code = e.code.yellow + ':'.red + ' ';
}
grunt.log.writeln(pos + ' ' + code + e.reason.yellow);
The reason I ask is I maintain grunt-notify
which shows desktop notifications via Growl/OSX Notification/etc when errors happen. This works via grunt.hook
into grunt.log.error
and grunt.log.warn
. Users want to find out about jshint errors without having a terminal visible. See dylang/grunt-notify/issues/5.
I'm thinking about creating a PR that would utilize grunt.log.error
or grunt.log.warn
. Do you have thoughts on this?
I have a .jshintrc that has "predef": {}
. When I grunt jshint
, it returns
Warning: Object #<Object> has no method 'forEach' Use --force to continue.
It looks like this is related to how the grunt task updates .predef
from an Array to the .globals
Object. In my case predef
is an Object, not an Array.
I have some ideas for improving the readability of the logged output.
(Pretend there are nice colors)
Before:
[L1:C1] W097: Use the function form of "use strict".
'use strict';
[L474:C54] W008: A leading decimal point can be confused with a dot: '.5'.
.style("fill-opacity", .5)
[L717:C50] W040: Possible strict violation.
var path = d3.select(this),
After:
1 | 'use strict';
^ Use the function form of "use strict". [W097]
474 | .style("fill-opacity", .5)
^ A leading decimal point can be confused
with a dot: '.5'. [W008]
717 | var path = d3.select(this),
^ Possible strict violation. [W040]
Thoughts?
If it makes sense to do so I'll create a pull request. I might put the formatting code in a separate module so it can be reused by other tools like jslint.
Thought you'd be interested:
https://github.com/isaacs/npm/issues/3643
Travis is failing the install when executing npm install grunt-contrib-jshint --save-dev
It would be great to have support for .jshintignores. Porting larger projects away from jshint cli to this plugin is sometimes not possible.
One feature I have found useful in the jshint command-line interface is the ability to include the error/warning code in each message. For example, the code for "Line is too long" is "W101". Since jshint allows messages to be suppressed at the individual message code level (via comments in the file) and thus be more granular than the named options allow, having the code in the output message is useful for knowing what code to use.
Currently, grunt-contrib-jshint doesn't display the code anywhere in the output text.
grunt-contrib-jshint currently pulls jshint 0.9.1, which has the following bug:
Could you please pull in the latest version (1.1.0), where this bug is fixed?
When using the new reporter option, a lot of errors are output with the message : Bad option: 'reporter'.
here is my grunt config :
jshint: {
options: {
"reporter" : "checkstyle",
"force" : true,
"browser": true,
"node": false,
"globalstrict" : true,
globals: {
angular : true,
console : true,
i18n : true,
$ : true
}
},
src: [
'<%= dirs.js %>/**/*.js'
]
By the way, is it possible to specify a xml file output for the checkstyle reporter?
I'm working on an AngularJS app, using the grunt to help me run the dev server, and attempt to package the thing for distribution. I'm very new to the entire tool-chain, grunt, yeoman, and AngularJS itself, and while I've managed to get to the point where I have something worth building, I'm still a bit dis-oriented with all of the tools involved.
My issue is that when I try to run grunt
, or grunt jshint:all
I get the following error:
Warning: Unable to read ".jshintrc" file (Error code: ENOENT). Use --force to continue.
Here's the verbose output that I was able to grab:
Running "jshint:all" (jshint) task
Verifying property jshint.all exists in config...OK
Files: Gruntfile.js, app/scripts/app.js, app/scripts/controllers/main.js,
app/scripts/controllers/onepod.js, app/scripts/controllers/pods.js,
app/scripts/services/podlist.js -> all
Reading .jshintrc...ERROR
Warning: Unable to read ".jshintrc" file (Error code: ENOENT). Use --force to continue.
Aborted due to warnings.
I was able to get something built by forcing it, but it wasn't completely successful, and I'd like to figure out what's going wrong here. Unfortunately, I have no clue which .jshintrc file is the issue exactly, as there are at least a dozen found within the project, and the error isn't terribly specific. Another note, I created was using Intellij for a bit with the project, it was created in the command line, but Intellij managed it. Not sure if that could have screwed something up. I am running grunt-contrib-jshint v0.3.0, grunt v0.4.1, grunt-cli v0.1.9 and nodejs v0.10.8.
Any help would be much appreciated!
When I try to use tilde in the context of !!~string.indexOf('otherstring'), JSHint via Grunt gives me the following lint error
Unexpected '~'
Is this usage really frowned upon or is this an unaccounted case for JSHint?
I wanted to try out the latest version of Grunt (currently 0.4.0rc2) but I can't seem to run a basic jshint on my files.
You can see my project repo/set-up here: https://github.com/Integralist/Grunt-Boilerplate
Specifically the Gruntfile content looks like this...
module.exports = function(grunt) {
/*
Grunt set-up:
npm install -g grunt-cli
npm install -g grunt-init
npm init
Requirements:
npm install [email protected] --save-dev
npm install grunt-contrib-watch --save-dev
npm install grunt-contrib-jshint --save-dev
npm install grunt-contrib-uglify --save-dev
npm install grunt-contrib-requirejs --save-dev
npm install grunt-contrib-sass --save-dev
npm install grunt-contrib-imagemin --save-dev
npm install grunt-contrib-htmlmin --save-dev
*/
// Project configuration.
grunt.initConfig({
pkg: grunt.file.readJSON('package.json'),
uglify: {
options: {
banner: '/*! <%= pkg.name %> | <%= pkg.version %> | <%= grunt.template.today("yyyy-mm-dd") %> */\n'
},
dist: {
src: './<%= pkg.name %>.js',
dest: './<%= pkg.name %>.min.js'
}
},
jshint: {
options: {
curly: true,
eqeqeq: true,
immed: true,
latedef: true,
newcap: true,
noarg: true,
sub: true,
undef: true,
boss: true,
eqnull: true,
browser: true,
globals: {
require: true,
requirejs: true,
jQuery: true,
console: true,
define: true
}
},
/*
In case there is a /release/ directory found, we don't want to lint that
so we use the ! (bang) operator to ignore the specified directory
*/
all: ['Gruntfile.js', 'app/**/*.js', '!app/release/**']
},
// Run: `grunt watch` from command line for this section to take effect
watch: {
files: '<%= jshint.all %>',
tasks: 'jshint' // add space separated list of items to watch
},
requirejs: {
compile: {
options: {
baseUrl: './app',
mainConfigFile: './app/main.js',
dir: './app/release/',
modules: [
{
name: 'main'
}
]
}
}
}
});
// Load NPM Tasks
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-contrib-jshint');
grunt.loadNpmTasks('grunt-contrib-uglify');
grunt.loadNpmTasks('grunt-contrib-requirejs');
grunt.loadNpmTasks('grunt-contrib-sass');
grunt.loadNpmTasks('grunt-contrib-imagemin');
grunt.loadNpmTasks('grunt-contrib-htmlmin');
// Default Task
grunt.registerTask('default', ['jshint']);
// Release Task
grunt.registerTask('release', ['requirejs']);
};
...but if I run either grunt
or grunt jshint
I get the error message: Warning: Cannot call method 'forEach' of undefined Use --force to continue
Does anyone know what I can do to get this working as the grunt-contrib-jshint GitHub page doesn't really help much as in way of example.
Thanks.
So I've notice with the switch to 0.5 I'm now getting super verbose, hard to grok output. Essentially what is happening is that there is a call to cli.run
foreach file is being linted, which creates a report per file. If a file happens to be ignore, you get the following for that single file.
0 files linted. Please check your ignored files.
Is there a reason for this behaviour?
Ideally reporters could still be utilised with a single call to cli.run
and we can get back to the good old days of
Current npm version is 0.2.0, I would love to have 0.3.0.
(I especially need fc6397e)
Greetings
Johannes
Is there a way to avoid having the jshint task stopping my grunt task on failure.
Use case is when I start my dev server with grunt dev
, I want to see jshint output in the console, but I don't want to prevent the dev server running if there are jshint issues. (however when I build the prod site with grunt build
I want jshint issues to stop the build process.)
I've implemented this workaround, but may be good to have something generic to do that:
I'm finding some strange properties to go alongside jshint.options out in the wild in the grunt contrib community, and I'd really like to know some more about what it is they are meant to do. You can see some here: https://github.com/jsoverson/grunt-template-jasmine-requirejs/blob/master/Gruntfile.js
grunt.initConfig({
// Task configuration.
jshint: {
options: {
node : true,
curly: true,
eqeqeq: true,
immed: true,
latedef: true,
newcap: true,
noarg: true,
sub: true,
undef: true,
unused: true,
boss: true,
eqnull: true,
globals: {}
},
gruntfile: { //Undocumented
src: 'Gruntfile.js'
},
lib_test: { //Undocumented
src: ['src/**/*.js']
}
});
Attempts to consult the source on how you are using them has led me to believe that you are not using them anywhere - I couldn't find anything in your scripts that utilize these properties. Am I mistaken? Is there a purpose for them? How many other undocumented properties are there/am I not finding my way to proper documentation?
Thanks,
I've got a project with several .jshintrc spreaded in different folders.
When I run jshint
command directly, the corresponding .jshintrc file will be found and the code linting works as expected.
When I run grunt jshint
however, It fails to find any .jshintrc. Hence produces loads of error messages because I've got asi enabled but the default is false.
My system is very old. Windows XP with cmd.exe. grunt jshint
doesn't work in neither cmd.exe nor Git Bash.
$ jshint --version
jshint v2.1.3
$ grunt --version
grunt-cli v0.1.9
grunt v0.4.1
The version of grunt-contrib-jshint is the latest, 0.6.0
I'm not sure if this is only the onevar setting or if the whole file is not linted for some reason. As you can see from the console ouput, it says it's linted but missses the obvious second var statement. I noticed this in a bigger grunt project but distilled it into a minimal example.
Curiously with the bigger project, in some files (such as the gruntfile itself) it actually does complain about the multiple var statements...
As discussed in gruntjs/grunt#514. How keen would you be to merge this here? We are using the 3.* version with this and we are happy with it.
We could maybe do a pull request for this here if you are in principle willing to merge the feature.
This is pretty cool.
Since it is now available on NPM, it would be nice for a bump in the contrib with the new version
Would there be any possibility of allowing us to provide our own JSHINT fn to the task, perhaps something along the lines of:
jshint: {
options: {
jshint: require( "../my-custom-jshint" )
}
}
The use case for it is so that if there's a long-standing jshint issue that doesn't seem like it's getting traction for whatever reason ( jshint/jshint#935 in my case ), we could fork jshint and provide it to the grunt task without also having to fork it.
As of 0.4.3
, the jshintrc
option contents are not merged with task/target options. This seemed to work as expected in 0.3.0
.
Sample config (abbreviated):
jshint: {
options: {
jshintrc: '.jshintrc'
},
gruntfile: {
options: {
globals: {
'module': true,
'require': true
}
},
src: ['Gruntfile.js']
}
}
In the above scenario, the gruntfile.options
object is ignored.
I use a custom reporter that I've pushed and installed over npm but it seems grunt-contrib-jshint doesn't find it if I only pass the module name:
This doesn't work:
'jshint-path-reporter'
Instead I have to use a path into the node_modules folder:
'./node_modules/jshint-path-reporter'
Not a major issue but it seems odd since the reporters are modules and they resolve with the modules package.json's main file (I didn't need to append 'index.js')
If grunt-contrib-jshint is configured in the Gruntfile
as follows:
grunt.initConfig({
jshint: {
all: ['**/*.js'],
options: {
jshintrc: '.jshintrc'
}
}
});
and a .jshintignore
has the following contents:
node_modules/**
running grunt jshint
results in the files in node_modules
still being linted.
When grunt is run in verbose (-v) mode, reporters get passed a grunt-specific dump of options that breaks the output.
Pull request fix incoming (Still getting the hang of github, please forgive me if I tag it incorrectly and make a new issue.)
Seen with grunt 0.4.1 and grunt-contrib-jshint 0.6.0
It would be nice to have the jshint reporter option available as part of the grunt task. This could then be used in CI like jenkins to display checkstyle reports.
Can you update the package.json to use latest JSHint version.
Is there any reason we don't just use the jshint cli directly? Meaning do this:
var jshintcli = require('jshint/src/cli/cli');
var gruntReporter = function(results, data) {
/* Output results in a grunt like format */
};
jshintcli.run({
args: this.filesSrc,
extensions: 'js',
reporter: options.reporter || gruntReporter
});
Or is require('jshint/src/cli/cli')
considered a bad practice? If so I'd like to send jshint a PR to expose that to require('jshint').cli
. This seems like it would fix all the requests to re-implement jshint things within this task.
I am attempting to use the syntax shown in the README to make violations halt release builds only, but getting a weird error when using the targets. My syntax is as follows:
jshint: {
options: {
jshintrc: '.jshintrc'
},
dev: {
options: {
force: true
},
files: ['./Gruntfile.js', '<%= cfg.js_src %>', '!<%= cfg.libs_dir %>/**']
},
release: {
files: ['./Gruntfile.js', '<%= cfg.js_src %>', '!<%= cfg.libs_dir %>/**']
}
}
and the error I get is Warning: Cannot use 'in' operator to search for 'src' in ./Gruntfile.js� Use --force to continue.
with an exit code of 3.
cf. gruntjs/grunt#326.
I don't have time or experience with grunt to incorporate it into this repository, but here is what I used locally to make it work. It isn't perfect, see https://github.com/jshint/jshint/blob/master/src/cli/cli.js for the exact method of how jshintignore
is utilised.
The main difference is that JSHint excludes along the way, whereas with grunt.file
it appears one has to first expand everything and then add a bunch if !
entries. There is probably a better way, though even for a large repository it still runs in under a second for me.
var get = {
// Get list of minimatch patterns that should be excluded
// from JSHint.
jshintExclude: function () {
var ignores = grunt.file.read( '.jshintignore' );
if ( ignores ) {
ignores = ignores.split( '\n' )
.filter( function ( ignore ) {
return !!ignore.trim();
} )
.map( function ( ignore ) {
if ( ignore.slice( -3 ) === '.js' ) {
return '!' + ignore;
}
if ( ignore.slice( -1 ) !== '/' ) {
ignore += '/';
}
return '!' + ignore + '**/*.js';
} );
get.jshintExclude = function () { return ignores; };
return ignores;
}
return [];
}
};
grunt.initConfig({
jshint: {
options: {
jshintrc: '.jshintrc'
},
all: [ '**/*.js' ].concat( get.jshintExclude() )
},
I'm trying to run jshint through grunt with:
grunt.initConfig({
pkg: grunt.file.readJSON( "package.json" ),
jshint: {
ignores: [
"src/wrapper/*.js"
],
files: [
"Gruntfile.js",
"make.js",
"src/**/*.js"
]
}
})
but no matter whether I place ignores
before or after files, the files in the wrapper
dir are still loaded and parsed by jshint. Can the README.md be extended for the ignores
parameter with an example snippet to show the use of files
in combination with ignores
, so that I (and others like me =) can see a proper code example that we can use in our own grunt files?
As descriped here there are issues with jshint + before and after concat. The solution provided didn't really seem like the sleekest thing around. Is there any way to make my gruntfile check before: and after: in a single run? I just do the following every time now.
grunt
grunt
This just doesn't feel right.
EDIT: I just realized the right method was editing the grunt.registertask file. This issue can be closed, I was being silly.
This might be silly (I could not find this in docs and examples).
Is there a way to specify the 'reporter' function as part of options?
Something like
jshint : {
options :{
reporter : reporterFn
}
}
It would be cool, if options defined in .jshintrc would get merged with options object.
I am seeing the following error trying to use the grunt jshint
task.
TypeError: Object #<Object> has no method 'options'
at Object.module.exports (/Users/patricklocal/Projects/personal/grunt/node_modules/grunt-contrib-jshint/tasks/jshint.js:18:24)
at Object.task.registerMultiTask.thisTask (/usr/local/share/npm/lib/node_modules/grunt/lib/grunt/task.js:109:15)
at Object.task.registerTask.thisTask.fn (/usr/local/share/npm/lib/node_modules/grunt/lib/grunt/task.js:58:16)
at Task.<anonymous> (/usr/local/share/npm/lib/node_modules/grunt/lib/util/task.js:343:36)
at Task.<anonymous> (/usr/local/share/npm/lib/node_modules/grunt/lib/util/task.js:319:9)
at Task.<anonymous> (/usr/local/share/npm/lib/node_modules/grunt/lib/util/task.js:346:11)
at Task.start (/usr/local/share/npm/lib/node_modules/grunt/lib/util/task.js:359:5)
at Object.grunt.tasks (/usr/local/share/npm/lib/node_modules/grunt/lib/grunt.js:143:8)
at Object.module.exports [as cli] (/usr/local/share/npm/lib/node_modules/grunt/lib/grunt/cli.js:36:9)
at Object.<anonymous> (/usr/local/share/npm/lib/node_modules/grunt/bin/grunt:19:14)
I have installed the grunt jshint plugin with npm install grunt-contrib-jshint --save-dev
and my grunt.js file looks like this...
/*global module:false*/
module.exports = function(grunt) {
// Project configuration.
grunt.initConfig({
jshint: {
all: ['test.js']
}
});
grunt.loadNpmTasks('grunt-contrib-jshint');
};
Any advice?
I know this is a minor issue but we all love to put comments in our config files :)
Currently the task just tries to load the .jshintrc
as JSON so any comments in the file would cause an error.
In fact jshint itself does allow comments in the file, it simply strips them before trying to load JSON.
I think it makes sense to do the same,
I have to following setup:
jshint: {
rjs: {
src:[
'requirejs-test/main/src/**/*.js'
],
options: {
jshintrc: '.jshintrc-rjs',
reporter: 'jslint',
reporterOutput: 'reports/jshint.xml'
}
},
...
running with --verbose
flag pollutes the reported xml file with console output (including colour tags) like ..
// reports/jshint.xml
Reading .jshintrc-rjs...�[32mOK�[39m
Parsing .jshintrc-rjs...�[32mOK�[39m
JSHint options: �[36mbitwise=false�[39m, �[36mcamelcase=false
:true,"beforeEach":true,"afterEach":true,"expect":true,"waitsFor":true}�[39m
<?xml version="1.0" encoding="utf-8"?>
<jslint>
...
like with JSON jshintrc but in YAML (to allow comments and such). Grunt should support YAML.
If you are interested I will submit a pull request.
You have the .travis.yml file in the repo, but the hook isn't setup. See http://about.travis-ci.org/docs/user/getting-started/
I have a custom task which runs ['connect', 'watch']
to run a server and run jshint when files are changed. I set watch to use force, so a failed lint wouldn't stop the server:
watch: {
scripts: {
files: ['Gruntfile.js', 'src/*.js', 'src/**/*.js'],
tasks: ['jshint:force'],
options: {
nospawn: true
}
}
},
jshint: {
all: ['Gruntfile.js', 'src/*.js', 'src/**/*.js'],
force: {
options: { force: true },
files: { src: ['Gruntfile.js', 'src/*.js', 'src/**/*.js'] }
}
},
In 0.3 there would be an alert noise and the terminal icon would bounce once. It seems like in 0.4 force
is making it fail quietly. Can I get the noise back without stopping the server?
Right now v0.9.1
of jshint is being used which unfortunately doesn't include the fix for jshint/jshint#494. Which means I have errors for escapements that shouldn't be errors.
Is there anyway you can bump the version so I don't get errors for these anymore? Current version of jshint in npm is v1.1.0
.
Thanks!
If I have Gruntfile.js like this:
grunt.initConfig({
jshint: {
all: ['Gruntfile.js', 'config.js', 'src/**/*.js'],
options: {
jshintrc: '.jshintrc',
force: true
}
}
});
And, in example, missing semicolon in src/foo.js, then i see console output like this:
So, the problem is what I instead of file with error I always see the first file in array.
This is possible because array index is hardcoded here: https://github.com/gruntjs/grunt-contrib-jshint/blob/master/tasks/lib/jshint.js#L90
hi there..
i've done a fresh checkout from the git repository but..
$ grunt test
Running "nodeunit:tests" (nodeunit) task
Testing jshint_test.js...F......
>> jshint - defaultReporterErrors
>> Error: Expected 3 assertions, 1 ran
>> at process.startup.processNextTick.process._tickCallback (node.js:244:9)
>> jshint - defaultReporterErrors
>> TypeError: Cannot read property 'length' of null
>> at exports.jshint.defaultReporterErrors (test/jshint_test.js:74:57)
>> at stdoutEqual (test/jshint_test.js:28:3)
>> at Object.exports.jshint.defaultReporterErrors (test/jshint_test.js:70:5)
>> at process.startup.processNextTick.process._tickCallback (node.js:244:9)
Warning: 2/15 assertions failed (48ms) Use --force to continue.
Aborted due to warnings.
But the 'travis build' succeeds.. How can that be ?
I'm running this on OSX with following setup.
grunt --version
grunt-cli v0.1.6
grunt v0.4.1
node --version
v0.8.16
Best
David
Example setup: https://gist.github.com/Lugribossk/5709321
This is with Grunt v0.4.1 and grunt-contrib-jshint v0.6.0.
In the following example ERROR, I would like to ignore these.
Linting app/scripts/app.js...ERROR
[L24:C9] W015: Expected '}' to have an indentation at 11 instead at 9.
};
According to the docs for jshint, it is possible to switch errors off based on a code, ie [+|-]W015. The docs mention:
Then, to hide this warning, just add the following snippet to your file:
/* jshint -W034 */
Is there a way to specify this in the options block?
jshint: {
options: {
jshintrc: '.jshintrc',
curly: false
},
all: [
'Gruntfile.js',
'<%= yeoman.app %>/scripts/{,*/}*.js'
]
},
The existing grunt-contrib-jshint task at the time of this writing is hard to change and has limited unit tests. Rather than work the required large changes into your existing codebase I've decided to make grunt-jshint-bfs.
The units of work have been isolated into different classes rather than a single exposed init function. I believe this makes them easier to test and easier to expose as an API to other consumers.
I've tried to make sure the critical parts of the code have test coverage, whereas it seems that unit testing has fallen by the wayside for the contrib task.
I've changed the options structure to be more explicit about what the jshint options are in an effor to separate them from the task specific options. I think this eliminates a lot of complicated option deleting code that is in the grunt-contrib-jshint codebase.
I, personally, do not think that file reading should be done synchronously via the grunt.file.read
function. Although my limited testing hasn't revealed any definitive improvements, I believe each file should be linted asynchronously for performance.
If we've previously run jshint on a file, it should be cached so that we do not need to lint it again. This is done through a combination of temp file based caching where a hash of the contents, the jshint options and the globals determine whether or not we need to lint the file again. This is on by default, but can be controlled via an option.
While there is an existing Pull Request open (#34) to implement reporters, I am not happy with the hard linking of the reporter files and the hacky overriding of stdout
necessary to make them work together nicely. I've ported over the existing xml and checkstyle reporters, and have plans to write a base legacy reporter class that will help others who have existing reporters built port them to be used with this task.
You guys are 2 space tab kinda guys, I'm a 4 space tab kinda guy. You guys are not fans of white space, I'm a big fan of it. Evidently you are also against single var statements for multiple assignment. I have no problem converting to your style if you want.
I'd love to hear some feedback and have a dialog about the points I've raised above. I've never understood the init function based architecture in use and I'm curious if I might be missing something.
I'd be happy to talk about starting up a new branch with this code and merging it in over time. I'm sensitive to the options structure change and understand that it might be something that a minor version would be incremented for.
As a final option, if all my code just makes you want to vomit in your mouth a little bit, I could just publish this as a separate task and check back in from time to time looking wistfully at your code and thinking of the oh so sweet merging we could have done together.
I'm using yeoman generators with grunt in my workflow. In my .jshintrc file
I have //jshint unused: false, evil: true
for example in my app.js file. When I run jshint app.js
I don't get any errors; however, when I run grunt jshint
I get errors "eval is evil" and " is defined but never used".
What's wrong here?
'use strict';
/* Filters */
angular.module('myApp.filters', []).
filter('interpolate', ['version', function(version) {
return function(text) {
return String(text).replace(/%VERSION%/mg, version);
};
}]);
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.