Add support for .vue files

[FelixTheodor]

closes #107

I added a comment matcher and a todomatcher for .vue-files, supporting oneline JS comments:
// comment
as well as multiline JS/CS comments:
/* comment */
and HTML comments:
<!-- comment -->

I also added some tests for the new file format, and everything seems to work so far.

[preslavmihaylov]

This is a very nicely done PR. I have several issues regarding styling & several others regarding additional test scenarios.

Overall, I'm pretty happy with the PR and I'll merge it once you address the changes.

On another note, what did you think about the codebase & how was the experience of extending this feature? Any comments/feedback for improving the codebase?

And how about any project features you feel are important?

[FelixTheodor]

Thanks for the very helpful feedback!

I refactored the code as you pointed it out since it all seem to be very reasonable to me. Gonna push these changes in a minute.

Regarding your general question, the first jump into code was a little confusing for me. I am used to have many little unit-tests written for single methods. This is often very useful when trying to understand and especially debug code for the first time. I couldnt find any of those tests here, so I started to try and write my own little helper tests. Quickly, I noticed that the structure of the code does not "allow" this kind of tests easily since I could not even create a valid call to a method "from scratch".
Therefore, I just started to write code "blindly" (without instant feedback), looked at the way other file-types are handled and later debugged it with some prints and the integration-test.
Apart from the lack of these unit-tests, I find the code itself very clear and instructive, so it was possible for me to grasp the idea behind most of the things I saw, and reprocude/adapt the concepts to the new problem.

[preslavmihaylov]

One additional open question pending

[preslavmihaylov]

Why is the location of this line 0?

[preslavmihaylov]

Shouldn't this be:

WithLocation("scenarios/vue/main.vue", 15).
ExpectLine("/*").
ExpectLine("TODO: ...").
ExpectLine("*/").

[FelixTheodor]

Oh, this is weird. I mean, you are right, but I get an error if I implement it like you proposed:

` No matching todo detected in any of the scenarios

    Actual:
    ERROR: Malformed todo
    scenarios/vue/main.vue:0: TODO: malformed CS/JS multline entry, missing number
    scenarios/vue/main.vue:1: */
    	> TODO should match pattern - TODO {task_id}:
    
    Remaining scenarios:
    (scenario #1)
    ERROR: Malformed todo
    scenarios/vue/main.vue:15: /*
    scenarios/vue/main.vue:16: TODO: ...
    scenarios/vue/main.vue:17: */
    	> TODO should match pattern - TODO {task_id}:
    
    (scenario #2)
    ERROR: Issue is closed
    scenarios/vue/main.vue:49:   color: blue; // TODO 2: online comment wellformed in code, BUT issue closed
    `

And here, the displayed line of the actual todo is zero. I'm confused. Do you have any idea why it behaves that way?

[preslavmihaylov]

This actually is a bug with the comment matcher implementation.

There are two issues:

• You are not matching the multiline css comments correctly. You should match /* some todo comment */, but instead you are matching some todo comment */
• You are not tracking the linecnt at which a multiline comment begins. It should be persisted when transitioning to the multiline comment state similar to how it's done here and later used here

[preslavmihaylov]

You can try reproducing this by:

• go build todocheck and copying the output binary to a comfortable location
• Adding a new file main.vue which contains the scenario from the test
• Add a new .todocheck.yaml file with contents:

origin: https://github.com/todocheck-tests/test-public
issue_tracker: GITHUB

• run ./todocheck & verify the results

You can try instrumenting some debug prints to see what's going on or use a standard debugger if you have one set up.

[FelixTheodor]

Hey, you were right, it was indeed a bug. I think the new commits I pushed fix it. At least, now all the testing works as expected. I also added another test for an invalid HTML multiline TODO, which also works.

But there is one other thing I noticed, and I am not sure if its a feature or a bug: The last line of every file is always ignored, also by other file matchers (checked PHP briefly). This means that multiline comments that are closed in the last line are not checked for errors (since they technically never become closed).

If this is indeed a feature, I'd be interested in an explanation for it. Maybe it would then be helpful to throw an error if the last line is not empty, since it could lead to missing TODOs otherwise?

[preslavmihaylov]

But there is one other thing I noticed, and I am not sure if its a feature or a bug: The last line of every file is always
ignored, also by other file matchers (checked PHP briefly). This means that multiline comments that are closed in the
last line are not checked for errors (since they technically never become closed).

The final testcase you've added:

		ExpectTodoErr(
			scenariobuilder.NewTodoErr().
				WithType(errors.TODOErrTypeMalformed).
				WithLocation("scenarios/vue/main.vue", 53).
				ExpectLine("<!--").
				ExpectLine("TODO : malformed HTML multiline entry").
				ExpectLine("-->")).

proves it otherwise. What exactly do you mean?

If your observation is indeed correct, then this is a bug. If you can reproduce it deterministically, could you open a bug with reproduction steps & share the details?

[preslavmihaylov]

Thanks for the very helpful feedback!

I refactored the code as you pointed it out since it all seem to be very reasonable to me. Gonna push these changes in a minute.

Regarding your general question, the first jump into code was a little confusing for me. I am used to have many little unit-tests written for single methods. This is often very useful when trying to understand and especially debug code for the first time. I couldnt find any of those tests here, so I started to try and write my own little helper tests. Quickly, I noticed that the structure of the code does not "allow" this kind of tests easily since I could not even create a valid call to a method "from scratch".
Therefore, I just started to write code "blindly" (without instant feedback), looked at the way other file-types are handled and later debugged it with some prints and the integration-test.
Apart from the lack of these unit-tests, I find the code itself very clear and instructive, so it was possible for me to grasp the idea behind most of the things I saw, and reprocude/adapt the concepts to the new problem.

Thank you for sharing this feedback!

The reason there are no unit tests is because I decided to experiment with this project by using only integration tests & no unit tests in order to test a hypothesis I had that well-written integration tests can save you from regressions without the big cost (in my eyes) of writing & maintaining unit tests.

I hadn't considered that there'd be people like you who use the unit tests as "hooks" you can use to learn the code more easily & test new code you write in isolation.

[FelixTheodor]

Thank you for sharing this feedback!

The reason there are no unit tests is because I decided to experiment with this project by using only integration tests & no unit tests in order to test a hypothesis I had that well-written integration tests can save you from regressions without the big cost (in my eyes) of writing & maintaining unit tests.

I hadn't considered that there'd be people like you who use the unit tests as "hooks" you can use to learn the code more easily & test new code you write in isolation.

You're welcome!

This is an interesting idea. I would guess it's a trade-off; on the one hand, people already familiar with the code can add more functionality to it more quickly, but on the other hand, people who try to figure it out what's going on from scratch have a harder time (or at least miss one powerful tool for it).

[preslavmihaylov]

I think your implementation now works well and I am happy to merge it.

Several follow-ups before we close this:

• could you verify your observation about the bug is correct? If so, could you open a bug for it with reproduction steps?
• Could you expand the table in the README with supported languages

[FelixTheodor]

I think I did all the follow-ups, see the new commit and #146