end_column cannot be null

[swissspidy]

We're sometimes getting the following error:

##[error]'output.annotations[1].end_column' cannot be null

It looks like endColumn as reported by ESLint can indeed sometimes be null.

Would be great if there'd be a check for that before adding the annotation:

eslint-annotate-action/src/analyze-eslint-js.ts

Lines 75 to 78 in 95223b5

	if (line === endLine) {
	annotation.start_column = column;
	annotation.end_column = endColumn;
	}

[ataylorme]

@swissspidy thanks for teh bug report. I haven't run into this issue but I can certainly account for it.

What version of ESLint are you running? If you can attach a copy of a report that has this issue that would be helpful.

[swissspidy]

I'm currently using ESLint 7.2, although the error has been happening even before ESLint 7.x was out.

Here's a report that has the issue:

lint-js-report.json.zip

It's from the https://github.com/google/web-stories-wp repo.

The issue seems to stem from jsdoc/check-tag-names warning about unexpected @todo tag in a function doc block, in case that helps.

[ataylorme]

@swissspidy for transparency I am going to test out https://github.blog/2020-06-18-introducing-github-super-linter-one-linter-to-rule-them-all/, which was just released. It seems to also provide a lint report/check, though it looks like it might not do annotations.

If it works for my needs I may adopt the GitHub maintained solution and archive this project. If you have thoughts on the GitHub Super linter or why this Action would still be a better fit I'd love to hear them.

[swissspidy]

Sounds good to me. I'm gonna test the super linter myself to see if it fits our needs and provide feedback here.

[ataylorme]

@swissspidy FYI here were my findings on the GitHub Super Linter:

Overall it looks like the GitHub Super Linter is missing two features that I like about this action.

1. Being able to extend custom ESLint rulesets/shared configuration. The Super Linter is in it's own environment and can only extend the few packages installed there (e.g. eslint:recommended).
2. Annotating PRs with code linting results, so the results are easily visible to the pull request author and not buried in the failed action workflow logs

Annotating PRs I could probably live without but our team has a custom, shared ESLint config that we extend. While we could use that with the Super Linter it would be the only config. The capability for projects to override rules when extending the shared config would be gone.

As an example, our shared config has a line length limit of 120 and some projects override that to 200, skip enforcing a few specific rules, etc.

edit it seems that the Super Linter is open to contributions. I'm not sure if I want to continue maintaining this custom action with the features I need or contribute upstream to the Super Linter. I would prefer the latter but I need to investigate if adding those features to the Super Linter is feasible.

https://github.com/github/super-linter/blob/master/.github/CONTRIBUTING.md

One additional thing to note is that [the Super Linter uses the latest version of ESLint|https://github.com/github/super-linter/blob/master/Dockerfile#L67] while this action uses the version of ESLint bundled with the project. This shouldn't be an issue as [the Super Linter is versioned|https://hub.docker.com/r/github/super-linter/tags]. If you pin a specific version of the Super Linter the ESLint version being used would be consistent.

[ataylorme]

@swissspidy version 1.1.2 has been published with the fix in #8. Thanks for reporting the issue

[swissspidy]

@ataylorme I'm now getting 'output.annotations[0].start_column' cannot be null in some areas...

https://github.com/google/web-stories-wp/pull/5572/checks?check_run_id=1500127987#step:8:9