Open the possibility to activate strict mode whilst being softer on specific paths.
At Doctolib we are in the process of pushing for isolated Engines (Privacy and Dependency) but we would like to take care of violations coming from test files at a later time (In the meantime, we are still interested in tracking them)
What approach did you choose and why?
This PRs will complement the exclude global property with a exclude_from_strict and allow to specify an array of path that will not trigger packwerk check.
For example, this configuration will continue to track test violations in the todo files, but will also trigger strict mode on all the other paths:
There are a few levels where this property could go:
packwerk.yml and apply for all engines and all checkers
package.yml and apply for one engine and all checkers
package.yml and apply for one engine AND be define separately for each checker
As in my mind it was a similar scope than the existing exclude feature, it made sense to have it globally.
I hesitated quite a bit with the "per Engine" approach, but I don't think this should fall down at the Checker level.
What should reviewers focus on?
It would be the first time I am proposing a change on Packwerk so it might not be as idiomatic as it should be.
Type of Change
[ ] Bugfix
[ ] New feature
[x] Non-breaking change (a change that doesn't alter functionality - i.e., code refactor, configs, etc.)
Additional Release Notes
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Include any notes here to include in the release description. For example, if you selected "breaking change" above, leave notes on how users can transition to this version.
If no additional notes are necessary, delete this section or leave it unchanged.
What are you trying to accomplish?
Open the possibility to activate
strictmode whilst being softer on specific paths.At Doctolib we are in the process of pushing for isolated Engines (Privacy and Dependency) but we would like to take care of violations coming from test files at a later time (In the meantime, we are still interested in tracking them)
What approach did you choose and why?
This PRs will complement the
excludeglobal property with aexclude_from_strictand allow to specify an array of path that will not triggerpackwerk check.For example, this configuration will continue to track test violations in the todo files, but will also trigger
strictmode on all the other paths:There are a few levels where this property could go:
packwerk.ymland apply for all engines and all checkerspackage.ymland apply for one engine and all checkerspackage.ymland apply for one engine AND be define separately for each checkerAs in my mind it was a similar scope than the existing
excludefeature, it made sense to have it globally. I hesitated quite a bit with the "per Engine" approach, but I don't think this should fall down at the Checker level.What should reviewers focus on?
It would be the first time I am proposing a change on Packwerk so it might not be as idiomatic as it should be.
Type of Change
Additional Release Notes
Include any notes here to include in the release description. For example, if you selected "breaking change" above, leave notes on how users can transition to this version.
If no additional notes are necessary, delete this section or leave it unchanged.
Checklist