We're not planning on creating a job specifically for some extensions that just lint javascript.

However, what we are doing is this: The javascript lint check is currently the first component in the new Grunt build tasks system.

Once we've migrated all crucial tasks from Ant build.xml to Gruntjs and have migrated to Zuul (instead of Gerrit Trigger), we can easily create a catch-all job for any repositories that don't have a dedicated job which would simply execute "grunt lint" (aka the "Universal Linter") that will run phplint, jshint, csslint, puppetlint etc.

-- Krinkle

On Nov 21, 2012, at 7:17 AM, Santhosh Thottingal santhosh.thottingal@gmail.com wrote:

Is there a plan to enabled this for MediaWiki extensions? For some of our extensions, we do jshnt check manually in local machines. It would be great if they also can be configured with Jenkins to run jshint.

Thanks Santhosh

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Nov 21, 2012, at 7:23 PM, S Page spage@wikimedia.org wrote:

I have vim set up [..]

That's great. If you're using a different editor, here's a list if all kinds of platforms and editors and how to use jshint in them:

http://jshint.com/platforms/

On Nov 21, 2012, at 7:23 PM, S Page spage@wikimedia.org wrote:

Should we be using .jshintrc per directory or lines like /*jshint multistr:true */ at the top of files? Or both?

Neither. Place .jshintrc in the root directory of the repository. JSHint travels up until it finds it. Falling back ~/.jshintrc in your home directory (e.g. for files not in a repository but just loose somewhere, opening them up in your editor would use that).

Although having it in your editor is nice, but for massive (recursive) running against a repository you can install jshint (npm install -g jshint). Used like "$ jshint ." (recursively the current directory), or pass it the path to a directory or file.

JSHint has had many versions and the behaviour of some rules has changed over the years. So make sure you run against the same (latest) version we use on the cluster (i.e. the version that matters, for jenkins, 0.9.1 currently).

Some editors have their own (possibly outdated) copy of jshint (I know SublimeLinter had an old version for a while). If you have node-jshint installed, I'd recommend configuring the linter plugin of your editor to shell out to your version of jshint (if it supports that).

-- Krinkle

I worked this out myself: I created a .jshintignore file \o/

https://gerrit.wikimedia.org/r/#/c/36919/2/.jshintignore

On Tue, Dec 4, 2012 at 1:22 PM, Jon Robson jdlrobson@gmail.com wrote:

This is now running on MobileFrontend [1] but needs some tweaking! It's awesome! Kudos to whoever enabled that.

Is it possible to blacklist certain files? For instance we have an external javascript file we pull in from another project (javascripts/externals/eventlog.js ) that I'd rather not run through jshint

What's the best way to do this?

[1] https://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/6/conso...

On Tue, Nov 20, 2012 at 2:27 PM, Krinkle krinklemail@gmail.com wrote:

...

Hey all,

For a while now we have .jshintrc rules in the repository and are able to run node-jshint locally.

TL;DR: jshint is now running from Jenkins on mediawiki/core (joining the linting sequence for php and puppet files).

I cleaned up the last old lint failures in the repo yesterday in preparation to enable it from Jenkins (like we already do for PHP and Puppet files). After some quick testing in a sandbox job on Jenkins to confirm it passes/fails accordingly, this has now been enabled in the main Jenkins job for mediawiki/core.

Right now only master and REL1_20 pass (REL1_19 and wmf branches do not, the next wmf branch will however pass).

Therefore is has only been enabled on the master branch for now.

Example success:

• https://gerrit.wikimedia.org/r/#/c/24249/
• https://integration.mediawiki.org/ci/job/MediaWiki-GIT-Fetching/7730/console

22:16:41 Running "jshint" task 22:16:48 OK 22:16:48 22:16:48 Done, without errors.

Example failure:

• https://gerrit.wikimedia.org/r/#/c/34433/
• https://integration.mediawiki.org/ci/job/MediaWiki-GIT-Fetching/7732/console

22:24:01 Running "jshint" task 22:24:08 >> resources/mediawiki/mediawiki.js: line 5, col 5, Identifier 'bla_bla' is not in camel case. 22:24:08 >> resources/mediawiki/mediawiki.js: line 5, col 12, 'bla_bla' is defined but never used. 22:24:08 >> 22:24:08 >> 2 errors 22:24:08 Warning: Task "jshint" failed.

So if your commit is marked as failure, just like with failures from phplint, puppetlint or phpunit: Click the link from jenkins-bot and follow the trail.

-- Timo Tijhof

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Jon Robson http://jonrobson.me.uk @rakugojon

Thanks Antoine! Currently JSHint doesn't get a vote on MobileFrontend (http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/10/conso... : SUCCESS (non-voting)). Is it possible to make it vote and -1 anything which disobeys jshint? This would be extremely useful.

I'm really excited by this, and I'm looking forward to qunit integration next ;)

On Wed, Dec 5, 2012 at 2:52 AM, Antoine Musso hashar+wmf@free.fr wrote:

Le 04/12/12 22:22, Jon Robson a écrit :

...

This is now running on MobileFrontend [1] but needs some tweaking! It's awesome! Kudos to whoever enabled that.

<snip> > [1] https://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/6/console

Hello Jon,

I did enable it but most of the credits come to Timo who packaged JSHint so it can be used by Jenkins :-]

That is still a bit a work in progress though, JSHint results are not being shown in Jenkins yet beside the console output.

-- Antoine "hashar" Musso

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

That's weird, it looks like browser is already set to true in .jshintrc, but I still get errors for window being undefined from Jenkins. Is Jenkins using the .jshintrc file?

Ryan Kaldari

On 12/5/12 10:48 AM, Ryan Kaldari wrote:

Can we set 'browser: true' in the jshint config so that it won't complain about window being undefined?

Ryan Kaldari

On 12/5/12 10:16 AM, Jon Robson wrote:

...

Thanks Antoine! Currently JSHint doesn't get a vote on MobileFrontend (http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/10/conso...

: SUCCESS (non-voting)). Is it possible to make it vote and -1 anything which disobeys jshint? This would be extremely useful.

I'm really excited by this, and I'm looking forward to qunit integration next ;)

On Wed, Dec 5, 2012 at 2:52 AM, Antoine Musso hashar+wmf@free.fr wrote:

...

Le 04/12/12 22:22, Jon Robson a écrit :

...

This is now running on MobileFrontend [1] but needs some tweaking! It's awesome! Kudos to whoever enabled that.

<snip> > [1] > https://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/6/console Hello Jon,

I did enable it but most of the credits come to Timo who packaged JSHint so it can be used by Jenkins :-]

That is still a bit a work in progress though, JSHint results are not being shown in Jenkins yet beside the console output.

-- Antoine "hashar" Musso

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

If the 'browser' option is set to true, it's supposed to automatically accept globals like window and document without having to explicitly exempt them. Not sure why that isn't working on Jenkins, though.

Ryan Kaldari

On 12/5/12 10:57 AM, Jon Robson wrote:

Are you setting this as a global variable? I had the same issue and realised it needed to be defined as an option

See https://gerrit.wikimedia.org/r/#/c/36919/3/.jshintrc for reference.

On Wed, Dec 5, 2012 at 10:51 AM, Ryan Kaldari rkaldari@wikimedia.org wrote:

...

That's weird, it looks like browser is already set to true in .jshintrc, but I still get errors for window being undefined from Jenkins. Is Jenkins using the .jshintrc file?

Ryan Kaldari

On 12/5/12 10:48 AM, Ryan Kaldari wrote:

...

Can we set 'browser: true' in the jshint config so that it won't complain about window being undefined?

Ryan Kaldari

On 12/5/12 10:16 AM, Jon Robson wrote:

...

Thanks Antoine! Currently JSHint doesn't get a vote on MobileFrontend

(http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/10/conso... : SUCCESS (non-voting)). Is it possible to make it vote and -1 anything which disobeys jshint? This would be extremely useful.

I'm really excited by this, and I'm looking forward to qunit integration next ;)

On Wed, Dec 5, 2012 at 2:52 AM, Antoine Musso hashar+wmf@free.fr wrote:

...

Le 04/12/12 22:22, Jon Robson a écrit :

...

This is now running on MobileFrontend [1] but needs some tweaking! It's awesome! Kudos to whoever enabled that.

<snip> > [1] > https://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/6/console Hello Jon,

I did enable it but most of the credits come to Timo who packaged JSHint so it can be used by Jenkins :-]

That is still a bit a work in progress though, JSHint results are not being shown in Jenkins yet beside the console output.

-- Antoine "hashar" Musso

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Le 05/12/12 19:16, Jon Robson a écrit :

Thanks Antoine! Currently JSHint doesn't get a vote on MobileFrontend (http://integration.mediawiki.org/ci/job/mwext-MobileFrontend-jslint/10/conso... : SUCCESS (non-voting)).

Is it possible to make it vote and -1 anything which disobeys jshint? This would be extremely useful.

That is entirely possible though jslint is non voting per default to avoid any troubles and let people that jshint is watching at them.

Only VisualEditor receives voting for now.

I would say we wait a bit till people learn to use jshint locally then we can start making vote. I don't really want to disturb everyone workflow :-)

I'm really excited by this, and I'm looking forward to qunit integration next ;)

That is the next step, Timo has been looking at phantom.js !!