You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The violation should start at the name of the association, not the method call. In this example, :summaries and :todos should be underlined (using packwerk-vscode, but I've validated that this problem occurs in packwerk's output). You can see that the length of the violating piece of code corresponds to the name, but the location is wrong.
I assume this was introduced with the recent parser change, in which case it could point to a bug in Prism's parser translator.
To Reproduce
Analyze a file with a violating association.
Expected Behaviour
The violation is attributed to the name of the association, which is an implicit constant reference
Version Information
Packwerk: 3.2.0
Ruby 3.2.2
The text was updated successfully, but these errors were encountered:
This actually seems like something that is more of an incompatibility between packwerk and packwerk-vscode.
Packwerk only outputs the starting column of the offense. Packwerk-vscode then guesses the end column of the offense from the length of the name of the inferred constant. In the case of references inferred from associations, that just doesn't work. It also won't work for partially qualified constants though since packwerk resolves them to fully qualified references.
Any possible fix would require packwerk to output start and end columns for each offense.
We can then decide whether the offense should include the whole association method call or only parts of it.
exterm
changed the title
[Bug Report] location column for violations through association inspector is wrong
[Bug Report] location column for violations through association inspector is wrongly displayed in packwerk-vscode
Apr 16, 2024
Description
The violation should start at the name of the association, not the method call. In this example,
:summaries
and:todos
should be underlined (using packwerk-vscode, but I've validated that this problem occurs in packwerk's output). You can see that the length of the violating piece of code corresponds to the name, but the location is wrong.I assume this was introduced with the recent parser change, in which case it could point to a bug in Prism's parser translator.
To Reproduce
Analyze a file with a violating association.
Expected Behaviour
The violation is attributed to the name of the association, which is an implicit constant reference
Version Information
The text was updated successfully, but these errors were encountered: