prontolabs / pronto-eslint Goto Github PK

View Code? Open in Web Editor NEW

9.0 3.0 50.0 34 KB

Pronto runner for ESLint, pluggable linting utility for JavaScript and JSX

License: MIT License

Ruby 100.00%

pronto pronto-runner eslint javascript linter

pronto-eslint's Introduction

Pronto runner for ESLint

Pronto runner for ESlint, pluggable linting utility for JavaScript and JSX. What is Pronto?

Prerequisites

You'll need to install one of the runtimes supported by ExecJS.

Configuration

Configuring ESLint via .eslintrc will work just fine with pronto-eslint, though it will not support searching higher up the path hierarch. To use an absolute path to your config, use ESLINT_CONFIG.

pronto-eslint's People

Contributors

Stargazers

Watchers

Forkers

doits bambooengineering akrulwich astrauka pmvrmc jameshuynh jeroenj abinoam byee322 theotherdon okrcentral tobischo johannlejeune classicvalues isabella232 mrsool josh08h emilio2hd ugniuspacauskasvinted

pronto-eslint's Issues

Support `.eslintrc.*` configuration files

ESLint configuration instructions say to use any of these .eslintrc.* formats; it seems like .eslintrc is actually being deprecated.

I had to rename my .eslintrc.json file to the deprecated .eslintrc to get my config options to work correctly.

Use a newer eslint version

Currently, pronto-eslint is using zendesk/eslintrb which itself bundles eslint v2.7.0.

Newer eslint versions have newer features, so being able to using these would be very good.

I already created a MR to update the bundled eslint version but it's not yet merged (zendesk/eslintrb#9)

As soon as this is merged, we should incorporate this here, too!

Including `jsx` files?

Is there any chance jsx could be added to this list? Or perhaps an ENV variable that could be set to allow for additional files to be recognized?

Unable to comment on PR

Environment:

[deploy@server ~]$ gem list | grep pronto
pronto (0.10.0, 0.9.5)
pronto-eslint (0.10.0)
pronto-flay (0.10.0)
pronto-jshint (0.10.0)
pronto-rails_best_practices (0.10.0)
pronto-rails_schema (0.9.1)
pronto-rubocop (0.10.0)
pronto-stylelint (0.10.0)

It seems there is a problem posting comment on a PR as follow:

Comment message:

Creating a comment from message: #<Pronto::Message:0x00000004382e68 @path=".eslintrc", @line=nil, @level=:fatal, @msg="Parsing error: The keyword 'const' is reserved", @runner=Pronto::ESLint, @commit_sha=nil>
Creating a comment from message: #<Pronto::Message:0x00000004509e58 @path=".eslintrc", @line=nil, @level=:fatal, @msg="Parsing error: The keyword 'import' is reserved", @runner=Pronto::ESLint, @commit_sha=nil>

Back trace:

Creating commit comment on 
POST https://api.github.com/repos/n5ken/lcola-saas/commits/comments: 404 - Not Found // See: https://developer.github.com/v3
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/octokit-4.13.0/lib/octokit/response/raise_error.rb:16:in `on_complete'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/faraday-0.15.4/lib/faraday/response.rb:9:in `block in call'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/faraday-0.15.4/lib/faraday/response.rb:61:in `on_complete'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/faraday-0.15.4/lib/faraday/response.rb:8:in `call'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/octokit-4.13.0/lib/octokit/middleware/follow_redirects.rb:73:in `perform_with_redirection'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/octokit-4.13.0/lib/octokit/middleware/follow_redirects.rb:61:in `call'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/faraday-0.15.4/lib/faraday/request/retry.rb:128:in `call'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/faraday-0.15.4/lib/faraday/rack_builder.rb:143:in `build_response'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/faraday-0.15.4/lib/faraday/connection.rb:387:in `run_request'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/faraday-0.15.4/lib/faraday/connection.rb:175:in `post'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/sawyer-0.8.1/lib/sawyer/agent.rb:94:in `call'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/octokit-4.13.0/lib/octokit/connection.rb:156:in `request'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/octokit-4.13.0/lib/octokit/connection.rb:28:in `post'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/octokit-4.13.0/lib/octokit/client/commit_comments.rb:63:in `create_commit_comment'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/github.rb:34:in `create_commit_comment'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/github.rb:49:in `create_pull_comment'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/formatter/pull_request_formatter.rb:11:in `block in submit_comments'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/formatter/pull_request_formatter.rb:11:in `each'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/formatter/pull_request_formatter.rb:11:in `submit_comments'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/formatter/git_formatter.rb:9:in `format'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto.rb:67:in `block in run'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto.rb:66:in `each'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto.rb:66:in `run'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/cli.rb:66:in `block in run'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/cli.rb:64:in `chdir'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/lib/pronto/cli.rb:64:in `run'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/gems/pronto-0.10.0/bin/pronto:6:in `<top (required)>'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/bin/pronto:22:in `load'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/bin/pronto:22:in `<main>'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/bin/ruby_executable_hooks:15:in `eval'
/home/deploy/.rvm/gems/ruby-2.3.3@happypower-server/bin/ruby_executable_hooks:15:in `<main>'

Pronto fails on .eslintrc

Recently updated my app to include webpacker and webpacker-vue.

now running pronto returns:
.eslintrc: F: Parsing error: Unexpected token import

Is it possible to prevent linting on the .eslintrc file?

Wrong line number for fatal errors from ESLint

Issue

Fatal errors from ESLint don't show the file or line number that caused the error. After looking at the code, it appears that this is because there's an expectation that all fatal errors are parser errors. One such example is using the class keyword when ESLint is set to a version of ECMAScript that doesn't support classes. Paths and line numbers should be displayed when fatal errors like the class keyword that contain this information are encountered.

I took an initial swing at getting this fixed and was able to get file paths and line numbers to correctly display. However, there are a couple of failing tests that are kind of hard to follow, so I haven't been able to figure out what's going on in a reasonable amount of time. I'll be referencing the WIP PR after creating this issue, but I wanted to create this issue for reference as I ask for help in the WIP PR.

Steps to reproduce

Add a file called ProntoEslintError.js that contains an empty Javascript class:

class ProntoEslintError {}

Add the file to the stage: git add .
Run pronto against staged changes: bundle exec pronto run --staged

Observe: Pronto displays a parser error showing .eslintrc as the offending file.

Expected: Pronto displays a warning showing the actual path and line number where the issue occurred.

Technical details

Gem version: 0.10.0
Operating system: Ubuntu 18.04.5

Loading (parsing) of .eslintrc (json) is not working as expected

I have figured out that the format suggested at https://github.com/zendesk/eslintrb/blob/master/README.md is not JSON.parse compatible.

Issueing a PR over there in a minute.
Opening an issues here as zendesk/eslintrb is not open for issues.
And to make you (@mmozuras) aware of the issue.

Eslint configuration file errors blow up silently

If the .eslintrc file as some errors or invalid data (for example, using an unsupported version of ecmaScript like 8) the linter shows no errors.

This is fixed by PR #11. What do you think?

Support for `.eslintignore`

It would be nice if the .eslintignore was respected.

Support status?

I would like to ask what is the status of the pronto-eslint gem, and whether we have alternatives to running ESLint with Pronto?

I see the gem was updated to run with the latest Pronto release, but two issues were closed yesterday with the following comment:

I think this runner is effectively obsolete as eslintrb hasn't been updated since 2016.

Indeed, eslintrb seems obsolete, but https://github.com/doits/pronto-eslint_npm (also unmaintained :( ) has shown that it is indeed possible to run eslint directly from NPM packages without the need of the eslintrb wrapper.

@ashkulz would @prontolabs be open to reviewing and merging a PR that brings that feature and removes the eslintrb dependency?