test circleci transform-class

[samouri]

seeing if class properties break circle
Looks like class properties were breaking.

summary
While working on a calypso pull request, @Copons noticed that newly introduced class properties were failing eslint. Linting is part of our standard automated testing, and so any branches that add in new (or modify old) class properties were failing on those lines, and also skipping unit tests.

The introduction of this error is probably related to the babel 7 upgrade: #23424

to repro locally

1. on master, commit a change that adds a class property.
2. run node bin/eslint-branch.js.
3. You should see an error emitted

how this pr fixes it
upgrades eslint, eslines, and babel-plugin-react.
We came to that conclusion after reading a couple related issues:

• Messages when running eslint: can't resolve reference #/definitions/basicConfig mozilla/activity-stream#3743
• Class properties resulting in false positive babel/babel-eslint#487

Note: I thought we had fixed a similar issue awhile back (I did). I believe it came back with babel 7.

cc @Copons @blowery @gwwar

[matticbot]

Test live: https://calypso.live/?branch=try/transform-class-props

[samouri]

@nosolosw: do you know if I will accidentally introduce any errors to eslines by upgrading eslint to v4.x here?

[samouri]

I'm not sure why, but it seems like the version of eslint before this branch was missing some no-unused-vars warnings that it should have been erroring on. I've fixed them in d65976d

I'll do some investigating to try and figure out why these were getting past eslint

[samouri]

I figured out the explanation for why this upgrade creates new errors:

It turns out that eslint sensibly will not warn about any unused vars that occur before the last used one. This makes a lot of sense for standard ordered arguments since if you are writing a function and only care about the second provided arg, you still need to name the first one:

function foo( x, y ) {
  return x; // error: variable y is unused
}

function foo( x, y ) {
  return y; // no errors here
}

They called this property after-used, because it only outputs errors on unused variables after the last used one.

Up until recently, eslint had a bug where they weren't treating unused destructured args as errors if there were args that occur after it, which doesn't make much sense:

function foo( { x, eatY }, y ) {
  return eatY( y ); // would not error but should report x as unused!!
}

This was fixed recently: eslint/eslint#8442

[blowery]

Confirmed that eslines is no longer yelling and the fixes seem to work. The build backs that up.

I think this is ok to go? Unsure what else to test. There's so much noise in a plain eslint run that it's hard to know if there's a diff.

[blowery]

a plain node_modules/.bin/eslint . run..

on this branch:

✖ 1631 problems (1621 errors, 10 warnings)
  943 errors, 0 warnings potentially fixable with the `--fix` option.

b3c182b, the commit this branch is forked from:

✖ 2305 problems (2295 errors, 10 warnings)

c24d721, the commit before babel-7:

✖ 1325 problems (1315 errors, 10 warnings)

so looks like we're back to the old ballpark...

[gwwar]

I tested a local change with this branch by adding a class property to a component.

Before npm install:

[~/checkouts/wp-calypso] (try/transform-class-props)$ git commit -am 'wip'
Found '/Users/kerryliu/checkouts/wp-calypso/.nvmrc' with version <v8.11.0>
Now using node v8.11.0 (npm v5.6.0)

> husky - npm run -s precommit


By contributing to this project, you license the materials you contribute under the GNU General Public License v2 (or later). All materials must have GPLv2 compatible licenses — see .github/CONTRIBUTING.md for details.


Prettier formatting file: client/me/help/help-contact/index.jsx because it contains the @format flag

/Users/kerryliu/checkouts/wp-calypso/client/me/help/help-contact/index.jsx
  91:2  error  'foo' is not defined  no-undef

after npm install:

[~/checkouts/wp-calypso] (try/transform-class-props)$ git commit -am 'wip'
Found '/Users/kerryliu/checkouts/wp-calypso/.nvmrc' with version <v8.11.0>
Now using node v8.11.0 (npm v5.6.0)

> husky - npm run -s precommit


By contributing to this project, you license the materials you contribute under the GNU General Public License v2 (or later). All materials must have GPLv2 compatible licenses — see .github/CONTRIBUTING.md for details.


[try/transform-class-props 262fa36828] wip
 1 file changed, 2 insertions(+)

[gwwar]

Note that I also see The react/jsx-space-before-closing rule is deprecated. Please use the react/jsx-tag-spacing rule with the "beforeSelfClosing" option instead. We may want to consider updating this in this PR or in a follow up.

[blowery]

LGTM. Errors still work as expected.

[jsnajdr]

I tested this PR on a patch where I'm adding a new React component with class properties and it works. I was getting linting errors with old ESLint, but these disappeared after the upgrade.

There is one warning during npm i:

eslint-eslines@0.0.6 requires a peer of eslint@^3.8.1 but none is installed.

Can we bump the peer dependency in eslint-eslines, release 0.0.7 version and include the upgrade in this PR, too? Cc @nosolosw who might want to help.

[blowery]

@jsnajdr looks like a 1.0.0 was cut a while ago that supports eslint@4?

Trying that out.

[blowery]

moved to eslint-eslines@1.0.0 in 4b22338

[jsnajdr]

@blowery Yes, @nosolosw created it as a part of ESLint 4 upgrade attempt, but that upgrade had to be reverted later. I think it was because of the same errors with class properties as we are finally resolving now.

[oandregal]

Hey, sorry for not being able to help here - I was AFK until today.

As @jsnajdr mentioned: I had to revert the ESLint v4 upgrade due to errors with class properties. Problem was that babel-eslint didn't support ESLint v4 at the time. I just checked and they changed that a few days ago.

So the only thing needed for this PR to work was to update the eslint-eslines version that I had already published when I first tried to update to ESLint v4. Glad I wasn't a blocker and you figured out!

Closing #18106 as this PR has addressed it.