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

--format=checkstyle option for tsc --noEmit #42453

Open
4 of 5 tasks
dennis-c opened this issue Jan 22, 2021 · 3 comments
Open
4 of 5 tasks

--format=checkstyle option for tsc --noEmit #42453

dennis-c opened this issue Jan 22, 2021 · 3 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@dennis-c
Copy link

Suggestion

πŸ” Search Terms

Checkstyle

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

We have automated checking for typescript errors in our CI tooling (Jenkins), using the following command ./node_modules/.bin/tsc --project ./tsconfig.json --noEmit > build-logs/typescript-error.log. Currently we save the output to a plaint text file, but we would like to be able to parse it in our CI. The standards most tooling follows is a format option which supports a checkstyle format, which can easily be parsed by most CI's.

See https://checkstyle.sourceforge.io/config.html#Configuration_XML_Structure for more information on how to format the xml.

It would be great to have a --format=checkstyle option we could add to our current command to get a formatted xml file with all errors.

πŸ“ƒ Motivating Example

Most of our current tooling already supports this, and this enables us to check code quality, fail builds, etc.
Screenshot 2021-01-22 at 10 28 59

πŸ’» Use Cases

We currently have checks for stylelint, eslint, php codesniffer, phpstan, psalm and htmlhint. It would be great if we could also easily identify and report which typescript errors exist within our projects and possibly fail a build if we encounter them.

@RyanCavanaugh RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Jan 22, 2021
@idan-at
Copy link

idan-at commented May 25, 2021

Any progress on this one?

I have a similar use case - I'd like to format the TS compiler errors a bit differently, so our CI can catch the errors and display them nicely (ATM, when a build fails, we need to manually search the errors in the logs).

Adding the option for other formats (including custom ones, using plugins?) can be extremely helpful.

@michal-kocarek
Copy link

I have same error. It is hard to integrate TS compilation steps into CI without being able to simply visualize the errors. There are packages that are parsing the console output of TSC, however it does not seem to be standardized enough to be stable.

Having ability to export errors with different reporter format (aka checkstyle), would be great.

@dennis-c
Copy link
Author

Just a small update, we have as a workaround started using https://github.com/bartekbp/typescript-checkstyle for parsing the errors to checkstyle and written a package ourselves to filter out messages from node_modules https://github.com/Moxio/checkstyle-filter-by-name

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants