Test plan:
* Run eslint —fix against a file that doesn’t have a copyright header
(Eg: eslint --fix app/coffeescripts/AssignmentDetailsDialog.js )
* it should add the copyright header for you
* run eslint on a file that already has a proper copyright header
* it should not duplicate it
Change-Id: I0bc05b6cc267fb74909f7a0fe0e93ecda1e2136e
Reviewed-on: https://gerrit.instructure.com/140757
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
This rule was configured to allow for conditional assignment
without forcing destructuring which requires the use of wrapping
parentheses and a lonely semicolon. This style was roundly
rejected after discussion.
Example:
let foo
;({foo} = bar)
Change-Id: I3cfe1be2ac18ce88481367830e2eb30effbc3340
Reviewed-on: https://gerrit.instructure.com/140916
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Jeremy Neander <jneander@instructure.com>
QA-Review: Jeremy Neander <jneander@instructure.com>
This makes prettier errors eslint warnings. So when you
`eslint --fix some/file.js` it will format it with prettier
to try this out, apply this commit and run eslint against your files.
this change will make it so it runs it through prettier and forces
your code to look like prettier would output. But it doesn’t force
Prettier formatting to pass eslint since they are just warnings so if
you really want to format your code differently than prettier you can.
Change-Id: I4f1cdf4962173002a7dc22138be06cc66b842190
Reviewed-on: https://gerrit.instructure.com/131773
Tested-by: Jenkins
Reviewed-by: Jeremy Neander <jneander@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
closes: CNVS-34337
* For now, you can only test things that don’t require any coffeescript
files
* Write your tests using es6 module syntax
* see app/jsx/shared/helpers/__tests__/parseLinkHeader.test.js for an
example
test plan:
* run `yarn run jest`
* you should see some output like:
PASS app/jsx/shared/helpers/__tests__/parseLinkHeader.test.js
PASS app/jsx/actAs/__tests__/ActAsModal.test.js
Test Suites: 2 passed, 2 total
Tests: 5 passed, 5 total
Snapshots: 1 passed, 1 total
Time: 3.072s
Ran all test suites.
* make sure it runs on jenkins build
Change-Id: Ia79cd8ce35dc863c4cc5ce7512998320c7cfdb84
Reviewed-on: https://gerrit.instructure.com/100685
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
…but still force `let foo=1, bar=2` to be:
let foo=1
let bar=2
I don’t actually find any value in enforcing this rule at all and think
we could ignore it altogether but rather than advocating we remove it
completely, this commit just makes it so you can combine uninitialized
variable declarations at the top.
I frequently see this in spec files where we do something like
let subject, result, whatever
//and then in a ‘beforeEach()’ we assign values to those
//and then in each test(..) they are used
What say ye all?
Test plan:
* look at follow-on commit to this that changes MessageStudentsSpec.js
* it should not have eslint errors about:
`error Split 'let' declarations into multiple statements`
Change-Id: I7aafac3a395bac221e9e9b3111a82d0af4671ddb
Reviewed-on: https://gerrit.instructure.com/134822
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
a common pattern to set a ref for a react element is:
<div ref={e => this.refName = e} />
But if you are using our eslint rules (currently set to
"no-return-assign": ["error", "always”]) it will force you to do:
<div ref={e => {this.refName = e}} />
And now, if you are using prettier, it will format that as:
<div ref={e => {
this.refName = e
}} />
That seems needlessly verbose. With this change you can now do:
<div ref={e => (this.refName = e)} />
And both eslint and prettier will be ok with that
Test plan:
* verify functions that return an assignment do what you want in eslint
Change-Id: I56abfdb21a7bf3f5b3eae8088f27749f41f2371c
Reviewed-on: https://gerrit.instructure.com/131788
Tested-by: Jenkins
Reviewed-by: Felix Milea-Ciobanu <fmileaciobanu@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
all of our code that uses AMD looks something like:
define([
‘jquery’,
‘underscore’
], ($, _) => {
$(doStuff)
…
It doesn’t make it any “better” to force people to remove
that blank line at the top of the callback. In fact, leaving it puts
it on par with what we already lint for to *enforce* a blank
line between es6 import or commonjs require() statements and the rest
of your code.
Change-Id: I3dd2051200f6bf458732940306cd044bf631b463
Reviewed-on: https://gerrit.instructure.com/112177
Tested-by: Jenkins
Reviewed-by: brian kirkby <bkirkby@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
…Because we have a ton of existing code that
Does things like `const $user_name = $('#user_name’)`
And it doesn’t make anything “better” to force people to
go around renaming all those. And, although with BEM / React
you probably wouldn’t write code like that in new stuff,
If the DOM ID really is #user_name, for greppability it arguably
is better to keep the js variable and the dom id the same.
(or at least it is not objectively worse than having one with
underscores and one in camelCase).
Change-Id: I042deb3a2bd612eaf74addb141015d288a7330fe
Reviewed-on: https://gerrit.instructure.com/112176
Tested-by: Jenkins
Reviewed-by: brian kirkby <bkirkby@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Closes: CNVS-36236
We now treat code in public/javascripts
exactly the same as app/jsx. Since we pass
it all to babel we can lint with the same rules
as we do app/jsx and you can use all the modern
syntax/features/babel goodness there. There is literally
no excuse to write old crapy javascript anymore.
Now we can start adding some commits that eslint -fix all the existing
stuff in public javscripts.
Test plan:
* if you run eslint public/javascripts/instructure.js it should
give you a bunch of warnings about converting things from var
to let/const and other stuff like that.
Change-Id: I5d400b958ae33f3f13f7f6a9c3505a4f7b5843db
Reviewed-on: https://gerrit.instructure.com/112146
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Test Plan:
- Breaking those rules will be okay or in the case of
named stuff it fails :)
Change-Id: I5d41ec8d12aee5a59b6f35da0a86ed1571950998
Reviewed-on: https://gerrit.instructure.com/100877
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
closes: CNVS-34124
These are it’s default rules:
"rules": {
"promise/always-return": "error",
"promise/no-return-wrap": "error",
"promise/param-names": "error",
"promise/catch-or-return": "error",
"promise/no-native": "off",
"promise/no-nesting": "warn",
"promise/no-promise-in-callback": "warn",
"promise/no-callback-in-promise": "warn",
"promise/avoid-new": "warn"
}
the only one I changed was set avoid-new to ignore
because I have noticed that there was a few times
where I really did need/want to make my own promise.
I am open to debate on what others think though
Test Plan:
* the eslint errors on your code that uses promises
should have the warnings you expect
Change-Id: I46e5f2d1d2ded2dba1e5aeb2ebcf303bcd4c5981
Reviewed-on: https://gerrit.instructure.com/98201
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Test Plan:
- Using ENV should not show as a problem anywhere
Change-Id: I4b37a95606755e21716df0dfb61f26a85e295fe9
Reviewed-on: https://gerrit.instructure.com/98198
Reviewed-by: Jeremy Neander <jneander@instructure.com>
Tested-by: Jenkins
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
This makes it so eslint handles situations where we don't have
ES2015+ available, while still allowing us to have our own common
rules.
Change-Id: I86b49a32433970afbcc48ef0f6fcdd7301795b63
Reviewed-on: https://gerrit.instructure.com/97872
Tested-by: Jenkins
Reviewed-by: Dan Minkevitch <dan@instructure.com>
Product-Review: Clay Diffrient <cdiffrient@instructure.com>
QA-Review: Clay Diffrient <cdiffrient@instructure.com>
Ryan Shaw