Page MenuHomePhabricator

Switch to eslint for our linting and our code styling in all Wikimedia JavaScript code
Open, NormalPublic

Description

NOTE: In April 2016, JSCS maintainers joined the ESLint team. Plans for making the migration easier can be found at http://eslint.org/blog/2016/04/welcoming-jscs-to-eslint

We have decided to switch from jshint and jscs to eslint for all our JavaScript linting and code styling.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Paladox raised the priority of this task from to Needs Triage.Nov 18 2015, 12:32 PM
Paladox added a subscriber: Paladox.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptNov 18 2015, 12:32 PM

the winner was eslint since it does both and is pluggable meaning you can create your own plugin for it.

Why is that specifically relevant for Wikimedia's usecases of linting?

This task is for the mediawiki core, extensions, skins.

So your proposal is to adjust the codebase of hundreds of code bases? Or is this a Continuous-Integration infrastructure task instead?

Well it is too see which one is better for linting and code styling.

So your proposal is to adjust the codebase of hundreds of code bases?

maybe.

So there is no Wikimedia-specific criteria to define the "better" in "better for linting and code styling"?

So there is no Wikimedia-specific criteria to define the "better" in "better for linting and code styling"?

No I am talking about using a more recent tool that is easily pluggable meaning Wikimedia can create its own rules easily .

Then please elaborate why it's more "easily". Vague words in like "better" or "easier" help nobody.
I'm asking again for clear technical criteria which are also relevant for Wikimedia's infrastructure.

I am not sure how to use eslint that is why I am suggesting evaluate it. But reading the information it says it is made to be pluggable meaning everything in it has its own plugins.

It will allow Wikimedia to create its own rules without needing to add it to the repo first.

The JSCS team has joined the ESLint team and 3.0 will be the last version of jscs so we should probably consider this now.
See: https://medium.com/@markelog/jscs-end-of-the-line-bc9bf0b3fdb2#.oot3wvgpu

TheDJ added a subscriber: TheDJ.Apr 18 2016, 11:29 AM

@Jdlrobson wow, that's huge, didn't see that one coming..

Thanks @Jdlrobson for spotting that.
As I and others have spent some time adding JSHint/JSCS tasks and tweaking their configuration in several repositories, we should make sure that the conversion is as painless as possible, but also that no rules get loosened in the process.
Please schedule the RFC promptly

Ricordisamoa updated the task description. (Show Details)Apr 18 2016, 1:20 PM

Looks like eslint is joining the jQuery foundation now http://blog.jquery.com/2016/04/19/eslint-joins-the-jquery-foundation/ a week after jscs joined eslint

Restricted Application added a subscriber: TerraCodes. · View Herald TranscriptApr 19 2016, 5:52 PM
Jdlrobson changed the task status from Open to Stalled.May 11 2016, 6:42 PM
Jdlrobson added a subscriber: Krinkle.

@Krinkle suggests holding off doing this until ESLint allows us to transparently switch over. There is likely to be a migration script as an output of that work that will make this effortless.

Jdforrester-WMF triaged this task as Normal priority.May 11 2016, 6:45 PM
Jdforrester-WMF moved this task from TechCom-RFC to Backlog on the Front-end-Standards-Group board.
Jdforrester-WMF moved this task from Backlog to TechCom-RFC on the Front-end-Standards-Group board.

@Jdlrobson and @Krinkle I think there is already a script that does it but not all the settings that are in jscs have been moved over to eslint yet.

By migration script I mean this https://github.com/brenolf/polyjuice

Per https://github.com/eslint/eslint/issues/5857#issuecomment-210100704

Also question about jshint should we migrate it or keep it with jshint. Reason I ask is since it is better to discuss now so when we migrate jscs and we decide to also migrate jshint we can do it at the same time.

I think we should stay with jshint.

I didn't run any analysis but my gut feeling is that JSCS configuration is more uniform than JSHint among repositories, also because of the preset. Moreover JSHint doesn't seem to be merging into ESLint as JSCS is. Therefore it seems wiser to start migrating JSCS only and trial the JSHint migration afterwards.

Paladox changed the task status from Stalled to Open.Aug 29 2016, 1:21 PM

They have created a guide on how we switch.

Not all configs are available yet.

https://github.com/eslint/eslint/blob/master/docs/user-guide/migrating-from-jscs.md

Change 307286 had a related patch set uploaded (by Paladox):
Switch to eslint from jscs and jshint for our linting

https://gerrit.wikimedia.org/r/307286

Not all configs are available yet.

I would consider this a problem, at least as long as we don't know, if these configs are used and/or imported to one of our projects.

Jdlrobson changed the task status from Open to Stalled.Aug 29 2016, 5:04 PM

I agree with Florian here. Let's wait a little longer. Even better identifying which rules are used in Wikimedia projects and need to exist in eslint would be very helpful.

I agree with Florian here. Let's wait a little longer. Even better identifying which rules are used in Wikimedia projects and need to exist in eslint would be very helpful.

Jhernandez added a subscriber: Jhernandez.

Is there any POC patch?

Given eslint --fix it should be easy to fix the (new if any) linting errors from eslint in most cases.

@Jhernandez none that I know of but feel free to use MobileFrontend as a testing ground to see what is covered and what is not!

He7d3r added a subscriber: He7d3r.Oct 23 2016, 5:39 PM
Jdlrobson changed the task status from Stalled to Open.Oct 26 2016, 3:14 PM

We recommend doing this on a project per project basis. Some tools are currently not in the eslint prefix that were previously covered so coverage is not 100% but adoption will surface these issues.

So feel free to submit patchsets for projects, but it should be up to the team maintaining the tool whether to merge or not.

Change 307286 abandoned by Paladox:
Switch to eslint from jscs and jshint for our linting

https://gerrit.wikimedia.org/r/307286

We should fork grunt-eslint and pin eslint to a specific version as it keeps breaking tests every time a new eslint version is released.

Upstream doint want to pin it so the only way would be to fork it and pin it and bump it every time there is an update.

We should fork grunt-eslint and pin eslint to a specific version as it keeps breaking tests every time a new eslint version is released.

I don't think forking is a good solution here. If we fork it, we'd have to manually update our fork every time and make a new release there - in addition to updating various repos that use our fork.

Instead, we can already pin the version directly in the repositories that use grunt-eslint by specifying eslint as its own devDependency. This way we only have to update package.json in repositories that use grunt-eslint when we want to update to a new version (as we would, anyway). No maintain burden of needing to create a release of our fork every time upstream has a release.

See also https://github.com/sindresorhus/grunt-eslint/issues/116.

Are we sure that will work because I thougt a dep will not override a sub dep of a dep.

+ we wont need to publish it on npm as we can use a GitHub link.

Change 328049 had a related patch set uploaded (by Paladox):
Pin eslint version

https://gerrit.wikimedia.org/r/328049

Change 328049 merged by jenkins-bot:
Pin eslint version

https://gerrit.wikimedia.org/r/328049

Change 339082 had a related patch set uploaded (by Jforrester):
build: Replace jscs/jshint with eslint and make pass; pin versions

https://gerrit.wikimedia.org/r/339082

Change 339082 merged by jenkins-bot:
build: Replace jscs/jshint with eslint and make pass; pin versions

https://gerrit.wikimedia.org/r/339082

Krinkle removed a subscriber: Krinkle.Feb 24 2017, 4:57 AM

Change 349355 had a related patch set uploaded (by Jforrester):
[mediawiki/extensions/wikihiero@master] build: Replace jshint and jscs with eslint

https://gerrit.wikimedia.org/r/349355

Change 349360 had a related patch set uploaded (by Jforrester):
[mediawiki/extensions/CheckUser@master] build: Replace jshint and jscs with eslint

https://gerrit.wikimedia.org/r/349360

Change 349360 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] build: Replace jshint and jscs with eslint

https://gerrit.wikimedia.org/r/349360

Change 349355 merged by jenkins-bot:
[mediawiki/extensions/wikihiero@master] build: Replace jshint and jscs with eslint

https://gerrit.wikimedia.org/r/349355

Change 354625 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/PageAssessments@master] build: Replace jshint and jscs with eslint; upgrade other devDeps

https://gerrit.wikimedia.org/r/354625

Jdforrester-WMF renamed this task from Switch to eslint for our linting and our code styling to Switch to eslint for our linting and our code styling in all Wikimedia JavaScript code.May 20 2017, 9:04 AM
Jdforrester-WMF updated the task description. (Show Details)

Change 354625 merged by jenkins-bot:
[mediawiki/extensions/PageAssessments@master] build: Replace jshint and jscs with eslint; upgrade other devDeps

https://gerrit.wikimedia.org/r/354625