We have decided to switch from jshint and jscs to eslint for all our JavaScript linting and code styling.
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
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
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
@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.
@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.
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
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.
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.
Is there any POC patch?
Given [[ http://eslint.org/docs/user-guide/migrating-from-jscs#fix | 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!
Seems like there's some issues that need fixing at https://github.com/wikimedia/eslint-config-wikimedia/issues
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
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.
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 339082 had a related patch set uploaded (by Jforrester):
build: Replace jscs/jshint with eslint and make pass; pin versions
Change 339082 merged by jenkins-bot:
build: Replace jscs/jshint with eslint and make pass; pin versions
Change 349355 had a related patch set uploaded (by Jforrester):
[mediawiki/extensions/wikihiero@master] build: Replace jshint and jscs with eslint
Change 349360 had a related patch set uploaded (by Jforrester):
[mediawiki/extensions/CheckUser@master] build: Replace jshint and jscs with eslint
Change 349360 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] build: Replace jshint and jscs with eslint
Change 349355 merged by jenkins-bot:
[mediawiki/extensions/wikihiero@master] build: Replace jshint and jscs with eslint
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
Change 354625 merged by jenkins-bot:
[mediawiki/extensions/PageAssessments@master] build: Replace jshint and jscs with eslint; upgrade other devDeps
No usage of jscs on Gerrit: https://codesearch.wmcloud.org/things/?q=jscs&files=package.json&excludeFiles=&repos=
For jshint (https://codesearch.wmcloud.org/things/?q=jshint&files=package.json&excludeFiles=&repos=) I made patches to clean up:
@Jdforrester-WMF @Paladox I'm thinking that we can close this one as well (T220036), there are no repositories on Gerrit which are using jshint or jscs. :)
Yeah, though it'd be nice to finish T250315 it's not strictly blocking this work. Well done, all.