How to use strict mode in packwerk and add it while still working on package_todo?

Tools Packwerk
1

This message was imported from the Ruby/Rails Modularity Slack server. Find more info in the import thread.

Message originally sent by slack user U71TN2WF04X

Hi :wave: I’m wondering about strict mode and how to make use of it.
This would be when I have finished resolving all the violations in my package_todo.yml , right? Is there a way to add this while still working on the package_todo? For example, in my pack A I know the current violations and I am working on them, but I don’t want anymore to be added to my packs/A/package_todo.yml

2

There’s not an easy way to do this with strict mode, since it relies on there being no violations. We’d need to keep a second, unalterable list of violations that represent the existing violations, and not let new violations in package_todo.yml that are not in that list. It might look something like this:

  1. Have a spec that has a count of packages and their violations, e.g. { 'packs_my_pack' => { 'privacy' => 3, 'dependency' => 10 }}
  2. Iterate over each pack. If it has a metadata field, e.g. no_new_violations, then compare the count of violations to the hard-coded count and fail the spec if they’re different
3

Message originally sent by slack user U71TN2WF04X

I was playing a bit with packwerk’s code and I have an idea of how that would work! I will polish it a bit and make a PR. Still there is a lot of packwerk code that I don’t know how it works haha, so better to make the PR and get reviews :slightly_smiling_face:

4

Cool, interested to see what you come up with!

5

Message originally sent by slack user U71TN2WF04X

Last week I was giving this some thought. I came up with the following problems:
• What if there is a violation that was resolved? The command should still remove it from the package_todo file even if you don’t want new violations.
• What if a violation is updated because it was moved from one pack to another. The violation is still the same, but it changed position inside the package_todo file.
I am struggling to cover these cases.
The first one is not that terrible because when you start working on the violations, you would remove one by one from the file and run packwerk check, if you remove a line and the command doesn’t come up with a violation, then it was removed earlier :shrug:
But the second one could be trickier. What if it is a known violation that can’t be resolved (or not yet), but it changed from one pack to another, then packwerk check will throw an error, and the file won’t be updated because of no_new_violations :disappointed:

6

I think the first one is straightforward – the logic can permit a violation to be removed with update no matter the setting, but can have different behavior for new violations.

I addressed the second one in danger-packwerk actually by getting the list of renamed files in the diff and seeing if any new violations have a corresponding removal and the location of the new violation is in the list of renamed files. However, in the context of packwerk, this sort of check is not really possible today. I think this is probably acceptable for now since it’s generally unsolved for any similar tool (e.g. rubocop registers a new error when a file is moved).