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

ability to capture (non-fixable) eslint errors/warnings? #704

Closed
gwhitney opened this issue Feb 8, 2022 · 5 comments · Fixed by #827
Closed

ability to capture (non-fixable) eslint errors/warnings? #704

gwhitney opened this issue Feb 8, 2022 · 5 comments · Fixed by #827

Comments

@gwhitney
Copy link
Contributor

gwhitney commented Feb 8, 2022

Versions:

  • prettier-eslint version: 13.0.0
  • node version: 16.13.12
  • npm (or yarn) version: npm 8.1.2

Problem description:

Currently, prettier-eslint explicitly discards errors/warnings about eslint rule violations, as it is focused just on amending code to be compliant where it can. But I use prettier-eslint-cli to run prettier-eslint automatically on save from my editor. In that use case, it would be convenient for such errors/warnings to be written to stderr -- if that happened, they would pop up in my editor when I saved a file, which would save a step of running eslint at the end to check for any unfixable problems.

Suggested solution:

Add an option to prettier-eslint to pass back eslint error/warning messages about rule violations, in addition to the amended code, so that prettier-eslint-cli could then (perhaps optionally) write those to stderr. (Note I have yet to file an issue about this on the prettier-eslint-cli repo because at the moment there's no way the information could be written to stderr, since prettier-eslint is not providing it.)

Thanks for considering.

@JounQin
Copy link
Member

JounQin commented Aug 15, 2022

PR welcome

@github-actions
Copy link
Contributor

Stale issue

@gwhitney
Copy link
Contributor Author

Oh, sorry I let this get stale. Working on a PR now. As far as I can see, the interface of format cannot be changed: it takes a code string and a path name where that code nominally resides, and returns a code string. So the plan I am working on in the PR is to add another export, tentatively named analyze, which takes the same arguments but returns a simple object with keys output whose value is the same string as format currently produces, and messages with all of the messages produced in the generation of output, if any. If that doesn't sound like a good plan or you feel the naming should be different, please advise.

gwhitney added a commit to gwhitney/prettier-eslint that referenced this issue Dec 17, 2022
  Adds another export `analyze` from this package, which behaves
  exactly like `format` except that it returns a simple object
  with properties `output` giving the formatted text and `messages`
  giving the eslint messages produced in processing the input text.
  Clients can call `analyze` instead of `format` if they wish, for
  example, to capture any errors that esling may have encountered.

  Resolves prettier#704.
@gwhitney
Copy link
Contributor Author

Confused why this is closed before #827 is merged?

@gwhitney
Copy link
Contributor Author

With #827 closed (what else can I do to help fix this?), could this issue be re-opened? It has not been resolved, and it was judged "PR welcome" initially. My apologies for the long period between that invitation and the PR I submitted, but please let me know if there is anything I can do to move toward a solution for this issue. Thanks!

@JounQin JounQin reopened this Dec 16, 2023
gwhitney added a commit to gwhitney/prettier-eslint that referenced this issue Dec 19, 2023
  Adds another export `analyze` from this package, which behaves
  exactly like `format` except that it returns a simple object
  with properties `output` giving the formatted text and `messages`
  giving the eslint messages produced in processing the input text.
  Clients can call `analyze` instead of `format` if they wish, for
  example, to capture any errors that esling may have encountered.

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

Successfully merging a pull request may close this issue.

2 participants