Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Eslint support #1477 #2843

Merged
merged 25 commits into from
May 23, 2019
Merged

Conversation

ResuBaka
Copy link
Collaborator

@ResuBaka ResuBaka commented May 1, 2019

Related issues

#1477 #2522

Short description and why it's useful

This adds eslint for typescript.
This help to have a more uniform formatting for all JavaScript,Typescript and Vue Files.

Which environment this relates to

Check your case. In case of any doubts please read about [Release Cycle]

  • Test version (https://test.storefrontcloud.io) - this is a new feature or improvement for Vue Storefront. I've created branch from develop branch and want to merge it back to develop
  • RC version (https://next.storefrontcloud.io) - this is a stabilisation fix for Release Candidate of Vue Storefront. I've created branch from release branch and want to merge it back to release
  • Stable version (https://demo.storefrontcloud.io) - this is an important fix for current stable version. I've created branch from hotfix or master branch and want to merge it back to hotfix

Upgrade Notes and Changelog

  • No upgrade steps required (100% backward compatibility and no breaking changes)
  • I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

IMPORTANT NOTICE - Remember to update CHANGELOG.md with description of your change

Contribution and currently important rules acceptance

Some more infos

What still needs or should be done is on the eslint rules.
Here i have tried to have the eslint rules so that there is not formatting changes needed. But here can maybe made some improvements.
@pkarw @filrak @patzick

I know that i should add a changelog but that i am going to add when it es ready to merge and the eslint and prettier rules are set on.

About the broken test

These i am going to fix when i know which rules we want to have in the eslint rules. When the current erros are okay from the rules i can fix them now. But here i want to wait until i know which rules we want to have.

The prettierrc has rules that are like the current style.
Only one thing changes with that, that the semicolons rule is true
which is the default and that is needed in typescript
With this we get rules that get triggert when prettier was not used.
Then it adds all typescript rules for prettier and typescript it self.
@ResuBaka ResuBaka changed the title Prettier eslint support Prettier eslint support #1477 May 1, 2019
@ResuBaka
Copy link
Collaborator Author

ResuBaka commented May 1, 2019

Here is the code when semi is set to true

    const wrapper = mountMixinWithStore(MicrocartProduct, storeMock, {
      propsData: { product }
    });

    (<any>wrapper.vm).removeFromCart();

@pkarw pkarw added this to the 1.10.0-rc.1 milestone May 1, 2019
@pkarw
Copy link
Collaborator

pkarw commented May 1, 2019

@ResuBaka
Copy link
Collaborator Author

ResuBaka commented May 1, 2019

I have now fixed most of them.

I needed to update "@typescript-eslint/eslint-plugin": "^1.7.1-alpha.17", "@typescript-eslint/parser": "^1.7.1-alpha.17" both to a alpha stage which has fixed a problem with semicolons.

Then i have updated the eslint vue package. I have done that because of the update of eslint i have seen that the old version in the package.json had es peer the version ^3 or ^4. That is why i have updatet it.

It would be grade to get some feedback on the still open erros on how some of them should be handelt?
Should they be fixed or should the rule be changed around them.

@ResuBaka
Copy link
Collaborator Author

ResuBaka commented May 2, 2019

For the v-for with an v-if error this can be fixed with:

  1. https://github.com/vuejs/eslint-plugin-vue/blob/master/docs/rules/no-use-v-if-with-v-for.md#allowusingiterationvar-true
"allowUsingIterationVar": true
  1. Change the loop into a template element. This i would need to test but i thing this would work.
<template v-for="(segment, index) in totals"> 
        <div
          :key="index"
          class="row pt15 pb20 pl30 pr55 "
          v-if="segment.code !== 'grand_total'"
        >

@ResuBaka ResuBaka changed the title Prettier eslint support #1477 Eslint support #1477 May 7, 2019
@ResuBaka
Copy link
Collaborator Author

ResuBaka commented May 7, 2019

I have removed the prettier comments from the PR as for now it only adds eslint typescript support.

This was a problem with the rule import/first which i have disabled
for this line as it needs to be done after the config is written to
disk.
@ResuBaka
Copy link
Collaborator Author

ResuBaka commented May 7, 2019

To summ all up.

  • Now all typescript files are linted with eslint.
  • Most new rules that would be errors are for now set to warning to see if these should be changed back to errors or disabled.
  • Then there are some cases where it can behave not 100% right as the eslint typescript is not as fare as tslint but they work hard on it.
    • For now i only found one case. Which is a problem with not-dev rule, that has problems with interfaces and issue for it can be found here.

@lukeromanowicz
Copy link
Contributor

lukeromanowicz commented May 10, 2019

This looks really awesome. The typescript rules look pretty the same as javascript we've been using. Thanks a lot for your hard work!

The only thing I'm concerned about is the code logic after changes because of the instability of ESlint's support for TS. The whole VSF has to be tested carefully after merging this one to ensure that nothing got broken :)

Copy link
Collaborator

@patzick patzick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ResuBaka thanks for this huge PR:)

Please update changelog.md with your description.

Also i've tried to test this in local env with windows, but yarn command is not passing with node-sass problem, i removed node_modules catalog and still with no success. Can you check if after removing node_modules your yarn command passes?

PS C:\git\vue-storefront> yarn
yarn install v1.13.0
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
info fsevents@1.2.9: The platform "win32" is incompatible with this module.
info "fsevents@1.2.9" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/5] Linking dependencies...
[5/5] Building fresh packages...
[-/4] ⢀ waiting...
[2/4] ⢀ node-sass
[-/4] ⠠ waiting...
error C:\git\vue-storefront\node_modules\node-sass: Command failed.
Exit code: 1
Command: node scripts/build.js
Arguments:
Directory: C:\git\vue-storefront\node_modules\node-sass
Output:
Building: C:\Program Files\nodejs\node.exe C:\git\vue-storefront\node_modules\node-gyp\bin\node-gyp.js rebuild --verbose --libsass_ext= --libsass_cflags= --libsass_ldflags= --libsass_library=
gyp info it worked if it ends with ok
gyp verb cli [ 'C:\\Program Files\\nodejs\\node.exe',
gyp verb cli   'C:\\git\\vue-storefront\\node_modules\\node-gyp\\bin\\node-gyp.js',
gyp verb cli   'rebuild',
gyp verb cli   '--verbose',
gyp verb cli   '--libsass_ext=',
gyp verb cli   '--libsass_cflags=',
gyp verb cli   '--libsass_ldflags=',
gyp verb cli   '--libsass_library=' ]
gyp info using node-gyp@3.8.0
gyp info using node@10.13.0 | win32 | x64
gyp verb command rebuild []
gyp verb command clean []
gyp verb clean removing "build" directory
gyp verb command configure []
gyp verb check python checking for Python executable "python2" in the PATH
gyp verb `which` failed Error: not found: python2
gyp verb `which` failed     at getNotFoundError (C:\git\vue-storefront\node_modules\which\which.js:13:12)
gyp verb `which` failed     at F (C:\git\vue-storefront\node_modules\which\which.js:68:19)
gyp verb `which` failed     at E (C:\git\vue-storefront\node_modules\which\which.js:80:29)
gyp verb `which` failed     at C:\git\vue-storefront\node_modules\which\which.js:89:16
gyp verb `which` failed     at C:\git\vue-storefront\node_modules\isexe\index.js:42:5
gyp verb `which` failed     at C:\git\vue-storefront\node_modules\isexe\windows.js:36:5
gyp verb `which` failed     at FSReqWrap.oncomplete (fs.js:154:21)
gyp verb `which` failed  python2 { Error: not found: python2
gyp verb `which` failed     at getNotFoundError (C:\git\vue-storefront\node_modules\which\which.js:13:12)
gyp verb `which` failed     at F (C:\git\vue-storefront\node_modules\which\which.js:68:19)
gyp verb `which` failed     at E (C:\git\vue-storefront\node_modules\which\which.js:80:29)
gyp verb `which` failed     at C:\git\vue-storefront\node_modules\which\which.js:89:16
gyp verb `which` failed     at C:\git\vue-storefront\node_modules\isexe\index.js:42:5
gyp verb `which` failed     at C:\git\vue-storefront\node_modules\isexe\windows.js:36:5
gyp verb `which` failed     at FSReqWrap.oncomplete (fs.js:154:21)
gyp verb `which` failed   stack:
gyp verb `which` failed    'Error: not found: python2\n    at getNotFoundError (C:\\git\\vue-storefront\\node_modules\\which\\which.js:13:12)\n    at F (C:\\git\\vue-storefront\\node_modules\\which\\which.js:68:19)\n    at E (C:\\git\\vue-storefront\\node_modules\\which\\which.js:80:29)\n    at C:\\git\\vue-storefront\\node_modules\\which\\which.js:89:16\n    at C:\\git\\vue-storefront\\node_modules\\isexe\\index.js:42:5\n    at C:\\git\\vue-storefront\\node_modules\\isexe\\windows.js:36:5\n    at FSReqWrap.oncomplete (fs.js:154:21)',
gyp verb `which` failed   code: 'ENOENT' }
gyp verb check python checking for Python executable "python" in the PATH
gyp verb `which` succeeded python C:\Users\Patryk\AppData\Local\Programs\Python\Python37-32\python.EXE
gyp ERR! configure error
gyp ERR! stack Error: Command failed: C:\Users\Patryk\AppData\Local\Programs\Python\Python37-32\python.EXE -c import sys; print "%s.%s.%s" % sys.version_info[:3];
gyp ERR! stack   File "<string>", line 1
gyp ERR! stack     import sys; print "%s.%s.%s" % sys.version_info[:3];
gyp ERR! stack                                ^
gyp ERR! stack SyntaxError: invalid syntax
gyp ERR! stack
gyp ERR! stack     at ChildProcess.exithandler (child_process.js:289:12)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at maybeClose (internal/child_process.js:962:16)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:251:5)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\git\\vue-storefront\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="
gyp ERR! cwd C:\git\vue-storefront\node_modules\node-sass
gyp ERR! node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0

@patzick
Copy link
Collaborator

patzick commented May 13, 2019

@ResuBaka yarn problem is not related to this issue, i'll test rest when get back my env to working state :)

please for now only update changelog.md

@ResuBaka
Copy link
Collaborator Author

Added the linting of typescript files to the changelog.

@patzick
Copy link
Collaborator

patzick commented May 13, 2019

@ResuBaka this yarn problem appears only when i switch to this branch, when im back on develop then it still keeps problem with node-sass in cache but after a while yarn command passes. That's why i thought that problem is with my local environment. Could you check why is this happening?

@ResuBaka
Copy link
Collaborator Author

I can check it later on my windows 10 machine.

On my Linux machine node 10.15.3 and yarn 1.16.0 i don't have that problem with and clean git clone and checkout.

When you can tell me your version i will try it later on my Windows 10 setup and see if i get the same problem. @patzick

@ResuBaka
Copy link
Collaborator Author

@patzick I have just test it on my windows 10 machine.
Node: 11.5.0
Yarn: 1.12.3

With that setup i have no problem running it.
We could test it in an travis-ci Windows setup and see if it is there, too. As it does not happen for me.

Maybe @pkarw or @filrak can test it and check if someone of them has the same problem.

But for me it looks more like you should try to update node or yarn to a newer version and check if that fixes it. Than an issue with my changes itself.

@pkarw
Copy link
Collaborator

pkarw commented May 17, 2019

Hi folks, is it ready to be merged in? @patzick

@pkarw
Copy link
Collaborator

pkarw commented May 17, 2019

Please make sure that this PR won't revert the: #2899

The rootStore.state.config is currently deprecated

@ResuBaka
Copy link
Collaborator Author

I have accepted all remote changes. So it should not have reverted anything from #2899.

@ResuBaka
Copy link
Collaborator Author

I have now fixed the new linting issues.

But there where some strange merge errors (broken typescript code) after i had merged developer. So maybe this should be tested a bit more that nothing is broken now.

Then is it normal that when i run the tests that i see this:
image
@pkarw.

@patzick
Copy link
Collaborator

patzick commented May 23, 2019

i've merged developp, improved some linting error and i'm merging it
thanks @ResuBaka for this great work!

@patzick patzick merged commit 1aa03f1 into vuestorefront:develop May 23, 2019
@ResuBaka ResuBaka deleted the prettier-eslint-support branch May 23, 2019 11:02
@pkarw
Copy link
Collaborator

pkarw commented Jun 1, 2019

Hi! I belive I found some issues regarding this feature - @lukeromanowicz @ResuBaka @patzick

  1. yarn eslint which is used by Travis - gets me different errors than yarn build and yarn dev. For instance with yarn eslint I see errors like: https://www.dropbox.com/s/sx6lbscba62nwy0/Screenshot%202019-06-01%2007.25.27.png?dl=0. With the yarn build i've got just the warnings (no errors) which causes CI to fail. We do have some misalligment in here.

  2. The same screen (https://www.dropbox.com/s/sx6lbscba62nwy0/Screenshot%202019-06-01%2007.25.27.png?dl=0) -> it's very hard to get the real issues when 99% of the lines are warnings. We should adjust the linting rules to the real/current code situation. I mean - we probably should skip some checks like unused vars which generates most of the warnings and fix the rest

@ResuBaka
Copy link
Collaborator Author

ResuBaka commented Jun 1, 2019

For the second problem we can add a script like lint:full and have the current lint default to eslint --quiet. But that is not a good solution and most warnings should be fixed or later changed to errors when most or all warnings are fixed as they are return types which should be used when you use typescript.

That would for now fix the problem so you can see the errors.

For the first one do you have a branch or commit with wich i could test it or see it? @pkarw

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants