- Mentioned In
- rEPI7e9c98a1a888: Final NoteDb migration updates
rERSL0c7b53b6b488: Update patch set 1
T119973: Convert all repos to use npm Jenkins job with jsonlint and eslint
T148225: Add jshint or ESLint to enforce coding conventions
T149201: Remove jshint and jscs in favor of eslint (linting and code style) in Reading Web code
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?
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.
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
By migration script I mean this https://github.com/brenolf/polyjuice
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.
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.
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.